[SCRUM] Aplicando Scrum en Trello

En un post anterior, expliqué cómo aprendí Scrum y los aspectos/principios/procesos de este framework. En este nuevo post, hablaré sobre 3 elementos importantes que forman parte de Scrum:

• Kanban
• Product Backlog
• Sprint Backlog

Además les comentaré sobre una herramienta de colaboración online : Trello.

Recordemos que Scrum busca entregar resultados de forma rápida y con menor costo, enfocándose en entregar productos y/o servicios que se alineen las necesidades del cliente. Cuando una organización decide implementar Scrum, es importante que todas las partes interesadas tengan mente que “el cliente está en primer lugar” [1]

Scrum se rige de 3 grandes pilares: Transparencia, Inspección y Adaptación

• Transparencia: Cada aspecto del proceso debe definirse por un estándar común a todos los integrantes del equipo
• Inspección: El avance hacia el objetivo fijado es responsabilidad de todos los integrantes del equipo
• Adaptación: La inspección constante, garantiza la capacidad de respuesta y la subsiguiente adaptabilidad del framework

Trello es un software que permite organizar proyectos en tableros. Permite ver cuáles son las tareas que se llevan a cabo, quién trabaja en una tarea determinada y cuál es el estado de un proceso [3]. La característica de Trello de trabajar con tableros permite automatizar el Kanban Board, el cual es utilizado frecuentemente en proyectos Scrum.

El Kanban Board es una herramienta que permite la visualización de nuestro trabajo y flujo de trabajo (workflow) para así optimizar dicho flujo. Por ejemplo en la imagen siguiente se muestra un Kanban Board básico con 3 pasos de nuestro flujo de trabajo, representados por columnas o “lanes” [4]

“To do”, “Doing” o “In progress”, “Done” (Por Hacer, En Progreso, Hecho)

Las tareas son representadas por “Kanban cards” (tarjetas, en tableros físicos son comúnmente post-it). Estas tarjetas son colocadas en los lanes de acuerdo a su estado actual de trabajo.

El Kanban Board es un gran aliado en la promoción de la transparencia del Scrum. Pues, cuando un equipo Scrum posee un Kanban Board, todos consiguen fácilmente visualizar el flujo de trabajo, cuales tareas están siendo ejecutadas, quién es responsable de qué, en que situación se encuentra cada tarea, etc. Existen mayores posibilidades de éxito cuando existe mayor transparencia en el proyecto ya que el equipo se siente más involucrada y aumenta su nivel de confianza. [5]

Ahora, profundizaremos en los artefactos de Scrum y cómo reflejarlos en Trello para ya dar inicio a nuestro proyecto Scrum

Los artefactos de Scrum son los que aportan la mayor transparencia en la información clave del proceso. Ellos son:

• Product Backlog: Es una lista con todos los requerimientos iniciales del producto
• Sprint Backlog: Es la lista de elementos seleccionados previamente del product backlog para ser desarrollados en el Sprint

Estos artefactos pueden ser representados en Trello, así el equipo tiene la posibilidad de colaborar activamente en la revisión/actualización de forma online. En [6], nos recomienda utilizar un board (tablero) para el Product Backlog y Sprint Planning y otro board por cada Sprint Backlog. El flujo es el siguiente: “Cuando el Product Owner aprueba un card/tarjeta, esta se mueve del tablero de Product Backlog al tablero del Sprint Backlog en el cual será desarrollada

En el siguiente link encontrarán unos templates del Product Backlog & Sprint Backlog en Excel.

En este otro link encontrarán un board con mucho material sobre cómo usar Scrum en Trello.

A continuación, se detalla una definición un poco más amplia de cada artefacto y cómo este puede ser representada en Trello

Product Backlog

Definición

Se trata de una lista priorizada que contiene descripciones breves de todas las funcionalidades deseadas para el producto en forma de historias de usuario. En proyectos ágiles no es necesario iniciar el proyecto documentado todos los requisitos en una única fase. Normalmente, el equipo y el Product Owner (PO), escriben y priorizan los items iniciales del Product Backlog, siendo estos items suficientes para que el equipo inicie a 1era iteración.

El Product Backlog irá creciendo y actualizándose a medida en que se aprende más sobre el producto y el cliente. [8]

En este artículo, encontrará recomendaciones sobre cómo redactar las historias de usuario.

Priorización y Estimación de Esfuerzo

Para realizar la priorización y estimación del esfuerzo de los items del Product Backlog, se tiene una técnica efectiva: Planning Poker.

Consiste en que cada miembro del equipo recibe un conjunto de cartas (baraja), cada carta posee un valor de una determinada secuencia. En seguida, cada historia de usuario (item del backlog) es analizada y cada miembro del equipo lanza una carta para abajo sobre la mesa, en ella estará el valor numérico de puntos (de esfuerzo/priorización) que el miembro considera justo para que esa historia se concluida

Se recomienda utilizar la secuencia de Fibonacci para el conjunto de cartas, los posibles valores son:

• ? :  El miembro no se siente capaz de atribuir un valor
• 0 : La tarea es irrelevante y debería ser descartada
• 0.5: La tarea necessta de um pequeño esfuerzo para ser concluda;
• … (infinito): Significa que la tarea es extremamente importante;
• Taza de café: Significa una pausa para pensar antes de tomar una decisión. Otros la denominan como que la tarea es muy fácil de realizar e incluso tomando una taza de café.

Los miembros que lancen las cartas con mayor y menor valor explicarán sus razones y en base a ellas, las cartas serán lanzadas nuevamente hasta llegar a un consenso entre todos los miembros y se logre la estimativa final.

 

Product Backlog en Trello

En [6] nos recomienda dividir nuestro Product Backlog board en las siguientes listas/lanes/columnas:

• Ideas. Descripciones sin detalles realizadas por el PO.
• Levantamiento de Requisitos: La lista de historias de usuario y funcionalidades deseadas.
• Requisitos listos para ser Estimados: Lista de requisitos completa
• Requisitos candidatos para Sprint

Ejemplo de Product Backlog en Trello, basado en template:

El PO es responsable de la priorización (tareas más importantes y de valor a ser realizadas lo más pronto). Aquellos requisitos ya correctamente definidos y completos son considerados como “Listos para ser Estimados” y son colocados en la 3era columna. En ella, el equipo es responsable de la estimación del esfuerzo. Como comenté esta puede ser hecha con Poker Planning, felizmente existe una extensión de Chrome: Scrum for Trello que nos permite asignar el puntaje a cada card (item del backlog) tal como se muestra en la imagen:

Durante la reunión de Sprint Planning, el equipo mueve los cards de “Listos para ser Estimados” a la 4ta columna “Candidatos para Sprint”

Se recomienda utilizar Etiquetas/Labels para identificar los diferentes items del Product Backlog

Posibles nombres de etiquetas:

Verde: Historias de Usuario (Como <rol> Yo quiero <deseo> así yo <resultado>)

Amarillo: Nuevo componente, es una nueva característica para el producto

Naranja: Issue o problema que ocurre durante el sprint. Es diferente a bug, pues un issue es parte del criterio de aceptación de la historia de usuario, solo cuando son resueltos, se da por concluida la historia.

Rojo: Bug, es un problema que perjudica el funcionamiento del producto. Se llama bug siempre y cuando es identificado DESPUÉS que una historia de usuario ha sido completada y aceptada por el producto owner.

Morado: Task/tarea que necesita ser hecha pues forma parte del Producto Mínimo Viable

Azul: Improvement/Mejora que tendrá el producto y no forma parte del Producto Mínimo Viable.

 

Sprint Backlog

Definición

Los métodos ágiles son iterativos e incrementales, es decir que el trabajo es dividido, refinado y entregado por partes o “entregables”. Por eso no es posible terminar todos los items del Product Backlog en una única iteración o Sprint[8]

Para trabajar de forma organizada, los items/historias de usuario que formarán parte de la iteración actual (con un timebox de 1 a 4 semanas) son colocados en un Sprint Backlog. Esto es realizado durante la reunión del Sprint Planning.

Allí para cada historia de usuario seleccionada, el equipo Scrum identifica las tareas que deberán ser ejecutadas para concluir dicha historia.

Sprint Backlog Board en Trello

Solo para recordar, en [6] nos dice que los únicos cards que aparecerán en este board son los aprobados por el PO para este sprint. El Sprint Backlog board podría tener las siguientes listas/lanes/columnas:

• About this Sprint: Se colocan datos básicos del Sprint a través de cards como los objetivos, métricas para medir el cumplimiento de los objetivos, duración, riesgos, etc.
• Sprint Backlog.  Aquí estarán los Cards que fueron designados del Product Backlog para ser realizadas en este sprint. Ver que ya tiene su puntuación.
• In progress. 
• QA bug reports.  Los encargados de QA colocarán los Cards que posean bugs en esta columna, así se evita de devolverlos al Product backlog o o colocarlas en progreso”.
• Ready for QA release. Cards considerados listos para ser revisados por QA pero que aún no están en ambiente de QA (esta columna no es obligatoria)
• Ready for QA: Cards siendo evaluados por QA
• Ready for Release.: Cards para ser colocados en producción
• Done. Cards puestos en producción.

Ejemplo de Sprint Backlog en Trello, basado en template:

 

***Extra** : El Gráfico “Scrum Burndown” o “Trabajo pendiente”

Es una herramienta visual que muestra el trabajo completado por día vs la tasa proyectada para completar un Sprint (release). Nos permite saber el tiempo que falta para completar las historias de usuario comprometidas en un sprint.

En [10] nos sugieren trabajar con 2 gráficos burndown:

• Día/Trabajo pendientes para completar los requisitos del producto o proyecto (product burndown chart), realizado a partir del Product Backlog priorizado. En este caso, el eje X es el número de la iteración y el eje Y es la cantidad de trabajo comprometido (en la unidad definida por el equipo, p.e. puntos)
• Horas pendientes para completar las tareas de la iteración (sprint burndown chart), realizado a partir del Sprint Backlog. En este caso, el eje X es el número de días de duración de la iteración/sprint y el eje Y es la cantidad de trabajo comprometido (en la unidad definida por el equipo, p.e. puntos, horas)

En [9], se muestran ejemplos prácticos de Burndown Charts y el significado de 2 líneas principales que se dibujan en el burndown:

• línea de trabajo pendiente (real)
• velocidad ideal de desarrollo (estimado)

En Trello, Luego de haber instalado la extensión Scrum for Trello, se incluirá el Burdown Chart:

Ese enlace nos abrirá una nueva ventana, en la que podremos ver nuestros gráficos por cada tablero que tengamos en Trello

Reflexiones

• Inicialmente, no vi un gran potencial para Trello como herramienta para soportar proyectos Scrum. Sin embargo, a medida que fue investigando más, me encontré con artículos (mencionados a lo largo de este post) que me ayudaron a convertir Trello en una herramienta efectiva y que soporte los principales artefactos de Scrum y con la ventaja de poder trabajar con mi equipo de forma online y ordenada
• Me queda pendiente una comparación entre Asana (software que he venido utilizando en LiOnline), Jira (que posee ya toda la configuración para proyectos ágiles) y Trello que ha sido revisado en este post.
• Si bien es cierto que hay defensores de tener el Kanban board físico, algunas veces no contamos con la suerte de tener a todo el equipo reunido en el mismo ambiente, por lo que un Kanban online ayuda a el pilar de la transparencia de Scrum se cumpla efectivamente.
• Estoy aplicando Scrum con Trello en un proyecto actual y parece que va yendo bien!, cualquier comentario/observación sobre esta aplicación, espero poder presentarlo en un futuro post.

Si ya has trabajado con Scrum, cuéntanos tu experiencia y estoy abierta a cualquier comentario/duda/corrección! 🙂

Referencias

[1] Como funciona o Scrum

[2] Aprendiendo Scrum

[3] Qué es Trello

[4] Kanban board

[5] Scrum com Trello – en MindMaster

[6] 5 tips for Using Trello for Scrum

[7] ¿Cómo empezar a utilizar Scrum en 10 minutos?

[8] O que é Product Backlog?

[9] Cómo hacer un diagrama de burndown?

[10] Gráficos de trabajo pendiente