El elemento que ha ido mutando mucho con cada Sprint es nuestro Task Board. En un principio nuestro pizarrón se dividía en cuatro columnas (ver más en este enlace: Primer planificación del Sprint):
Backlog, Sprint Backlog, En proceso y Terminado.

Un primer cambio fue separar el Backlog del pizarrón. Durante el Sprint, las tareas del Backlog no son tan importantes, y agregan ruido al panorama. Las tareas a finalizar en cada Sprint están en el Backlog del Sprint, por lo que los otros Product Backlog Items no hacen más que mostrar que todavía queda mucho por hacer…

Pegamos unas hojas blancas con cinta en la pared, al lado del pizarrón, y movimos todos los PBI del Backlog para ahí. Esto nos dió más espacio, bienvenido a medida que se fueron atomizando las tareas (lo que se traduce en más post-its).

Agregué una referencia visual aprovechando el pizarrón. En la columna de Terminado, escribí los objetivos del Sprint, y los días que faltan para que termine, cambiando este número en cada Daily Meeting (todavía tengo pendiente el Script para cambiar automáticamente el día en el pizarrón 😛 ). Esto nos permite ver cuál es el objetivo que queremos alcanzar a diario, para no desviarse de la dirección del Sprint, y cuánto tiempo nos queda.

También estamos usando referencias de colores en los post-its para identificar distintos tipos de tareas. Los post-its amarillos grandes son las historias de usuarios. Los amarillos más chicos definen las tareas. Los rojos son usados para errores y control de calidad y los verdes para tareas sin prioridad. Además, como todavía no hemos aplicado la estimación de tareas (lo hacemos de forma muy especulativa en cada planificación), le agregamos un punto rojo por día de trabajo a cada tarea en la columna de «En progreso». De esta manera podemos identificar las tareas con problemas de forma ágil.

Contamos ahora con un control de calidad y testing. Uno de los integrantes del equipo se encarga de esto, por lo que se agrega para historias de usuario o tareas específicas, la tarea «Control de calidad». Por esto debimos agregar un renglón en la columna de «en proceso», donde los desarrolladores colocan sus tareas cuando a su criterio están terminadas. Cuando una tarea está «pronta», se pasa a testing, y el tester saca tareas rojas (errores) si son necesarias, pasando la tarea a finalizado cuando se deba.

En un principio traté de seguir la filosofía minimalista en el task board. Esto por influencia directa de XQA quien en su blog de gestión visual comenta en la entrada Etiquetas de estado y las tres columnas (en inglés):

«Menos es más». Has oído esto antes, ¿cierto?

Esto aplica particularmente a la gestión visual (…) cualquier elemento visual que no agregue valor es desperdicio.

Sin embargo, nuestra aplicación de Scrum hizo que el task board fuera agregando nuevas separaciones. Otra sección nueva fue la de GUI, en la columna de en proceso, para que los encargados de la GUI agregaran elementos o arreglos a las interfases gráficas. Cada miembro del equipo que necesite algún cambio / mejora / nuevo elemento en una interfaz, ingresa una tarea en esta nueva separación. Si al equipo le queda más cómodo trabajar así, agrega valor.

Una unidad de trabajo puede tener tres estados básicos: «No comenzado», «En progreso» y «Terminada». La mayoría de los taskboards que tienen más de tres columnas están dividiendo «En progreso» en fases intermedias secuenciales. Ejemplo típico: «A validar».

Hay muchas razones por las cuales intentaría evitar usar columnas adicionales (…) pero lo más importante desde el punto de vista de gestión visual – es que crea elementos visuales extra (más columnas). También usa más espacio del taskboard, el cual puede ser escaso.

XQA plantea una solución más eficiente para este asunto, que podríamos llegar a poner en práctica, usar etiquetas de estado.

Como nos enseñaron en el curso de CSM, Scrum no tiene una sola forma de implementarse. Según el equipo y el trabajo a realizar, las distintas columnas del taskboard y otras referencias visuales pueden ayudar o no, depende. Es una metodología bastante evolutiva, ya que cada equipo y Scrum Master la va adaptando a sus necesidades según le venga mejor.

Uno de los temas a la hora de implementar Scrum, es qué columnas se van a usar en el task board. Algunos separan el task board en 4, 5 o más columnas. El task board debería ser una representación del estado del proyecto, que muestre a simple vista la situacion actual. Debería ser una referencia para saber en qué va la cosa con solo mirarlo. Por lo tanto, habría que tratar de mantener el nivel de complejidad al mínimo posible. De todas formas, como todo en Scrum, su implementación debería irse adaptando a las necesidades del equipo de trabajo.

Al principio de mi anterior implementación de Scrum, usábamos el pizarrón como Task Board. Más adelante, usamos un espejo que había en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida, pero ahora lo enfrentamos con más experiencia y otro conocimiento.

Usamos post-its de distintos colores para diferenciar tipos de tareas.
Referencia de colores:

• Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint.
• Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo.
• También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre.

Todos los movimientos en el Task Board se relizaban únicamente en el Daily Meeting, de manera que todo el equipo estuviera al tanto de lo que sucedía con el proyecto, y por el compromiso que implica llevar una tarea a la columna de “finalizado”.

Así fue como decidimos usar el task board en ese momento, y era lo que nos sirvió. Cada equipo debe adaptarlo a sus necesidades y aprender de la experiencia en su uso diario.