La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar mediante un tablero o pizarra de tareas (Scrum Taskboard) que actúa como radiador de información. A continuación se muestra cómo construirlo y un ejemplo de su uso.

Construcción del tablero

Material

• Pizarra blanca o cartón pluma, como mínimo de 100 cm x 70 cm, marcando las áreas del tablero con cinta adhesiva de colores.
  • Idealmente, el equipo debería de disponer de una superficie el doble de grande, para poderse ver y leer bien a cierta distancia, así como tener suficiente espacio físico para hacer delante suyo la reunión diaria de sincronización (Scrum daily meeting).
  • En su defecto, se puede utilizar papelógrafo o corcho.
• Rotuladores permanentes de color negro, rojo y verde.
• Regla de 50 cm.

 Dimensiones 

La distribución de zonas se ha realizado de la siguiente manera:

• En la parte superior se dispone una fila específica para tareas no planificadas, aquellas que no son parte de los requisitos/objetivos de la iteración pero que es necesario hacer de manera urgente (errores en producción, urgencias del cliente, etc.). De esta manera podremos visualizar cuanto somos de reactivos en lugar de planificados dentro de la iteración.
• A continuación hay una fila reservada para la mejora continua, donde se podrán las tareas fruto de retrospectivas anteriores y que queremos que realizar en esta iteración. Sólo pondremos aquí aquellas tareas que no sean asociables a un objetivo propio de la iteración.
• Se ha dejado más espacio para la columna de tareas no iniciadas, de manera que quepan todas las que se identifican en la reunión de planificación de la iteración (sprint planning). Notar que el espacio para tareas en curso es menor, dado que deberían ser las mínimas posibles para favorecer el flujo eliminando el multitasking. Similarmente, el número de objetivos abiertos en curso (WIP, Work In Progress) debería ser el mínimo posible y ser resueltos de arriba a abajo, según la prioridad indicada en el Product Backlog.
• La zona de impedimentos está destinada a la lista de obstáculos que pueden impedir que el equipo avance, que consiga los objetivos de la iteración o del proyecto, u otros riesgos que requieren una atención especial. Es conveniente indicar quien es el responsable de su solución (un miembro del propio equipo o el Facilitador (Scrum Master), dado que es una de sus principales atribuciones). Se gestionan de manera similar a las tareas (pendientes, en curso, hechos).
• La zona de retrospectiva servirá para ir anotando durante la iteración los aspectos que están funcionado bien (+, Pluses) así como los problemas que vamos identificando (Δ, Deltas).
• En la zona libre de la derecha situaremos, encima, información propia del proyecto y, debajo, información propia de la iteración (explicado más adelante).

Resultado de la construcción

Las ventajas de utilizar como base el cartón pluma son:

• Su poco peso, lo cual permite llevar el tablero fácilmente desde la zona de trabajo del equipo a una sala para, por ejemplo, hacer la reunión de planificación de iteración (sprint planning).
• Su modularidad, que permite adaptarlo a diferentes tamaños de equipo (las dimensiones del tablero de este ejemplo son las adecuadas para un equipo de 5 personas). Además de existir formatos de tamaño mayor e inferior, si es necesario en nuestro proyecto, podemos utilizar varios tableros y disponerlos uno al lado de otro, cambiar su orientación (horizontal-vertical), etc.

El tablero como radiador de la información de referencia para el equipo

El tablero es un radiador de información,  difunde el estado actual de la iteración (actualizado en la reunión diaria de sincronización (Scrum daily meeting), por lo que debe estar visible desde los puestos de trabajo del equipo con sólo hacer un movimiento de cabeza. También es especialmente útil en las reuniones que realizamos durante la iteración,  por lo que en él ponemos aquella información que queramos  consultar fácilmente cuando tengamos conversaciones delante del tablero:

• La leyenda con el nombre de los miembros del equipo, su código de colores, fotos.
• Información general del proyecto
  • La definición de hecho, que nos servirá como base inicial para hacer el despiece de objetivos de la iteración en tareas durante la reunión de Planificación de la iteración (Sprint planning).
  • La lista de objetivos priorizada del proyecto (Product Backlog).
  • Modelos del producto que se está desarrollando, a los que referirnos cuando expliquemos algo a los demás. De esta manera todos los miembros del equipo tendrán una misma visión, les sirvirá de apoyo cuando comuniquen cosas y ayudará a que utilicen una misma nomenclatura. Típicamente: diagrama de entidades del dominio, procesos o bloques funcionales e integraciones, etc.
  • Indicadores del proyecto: Product Backlog Burndown Chart, tendencias de defectos, etc.
• Información propia de la iteración
  • El objetivo de la iteración.
  • El gráfico de horas pendientes de la iteración (Sprint burndown chart).
  • Un calendario con los principales eventos del mes que tenemos que tener en cuenta.
• Cualquier otra información que nos interese tener muy a mano.

Planificación de la iteración (Sprint Planning)

Durante la reunión de planificación de la iteración, se va incorporando al tablero siguiente información:

• En la columna de la izquierda se irán situando los objetivos de producto (Product Backlog Items) que el equipo se compromete a completar en la iteración, ordenados por prioridad para el cliente (Product Owner). Estos objetivos se pueden redactar, por ejemplo en formato de historias de usuario o, simplemente, con un título y un detalle (preferiblemente que indique qué pruebas se van a realizar para demostrar que el objetivo está conseguido).
• A la derecha de cada objetivo se pondrán, en la columna “pendientes”, las tareas necesarias para poder completarlo, indicando las horas estimadas para su resolución, que iremos actualizando en las reuniones diarias de sincronización (Scrum daily meetings).
• En su zona específica, dispondremos las tareas de mejora continua que se han derivado de la retrospectiva de la iteración anterior, que queremos resolver durante esta iteración y que, por tanto, consumirán tiempo de alguna persona.

De esta manera visualizaremos todos los tipos de tareas en que trabajan los miembros del equipo.

Ejecución de la iteración

• • Ponemos en color rosa las nuevas tareas que vayan apareciendo, sean:
    • • Tareas  asociadas a objetivos / requisitos / historias de usuario que no fueron identificadas en la reunión de planificación de la iteración.
    • Tareas inesperadas y no asociadas a objetivos pero que exigen nuestra resolución dentro de la propia iteración (en la zona “no planificado”).
      • De esta manera podremos obtener métricas de trabajo no planificado [2] y en la retrospectiva revisaremos cuáles son las tareas que han aparecido de color rosa, lo cual nos permitirá saber, por ejemplo, si es que tenemos que mejorar nuestra definición de hecho o bien si tenemos que reflexionar y realizar alguna acción para intentar minimizar tareas no previstas.

• • Marcamos con un gomet rojo los objetivos y/o las tareas con más riesgos, aquellos que queremos tener controlados con más atención.

• • Cuando suceda alguna cosa que queramos comentar en la retrospectiva, la ponemos en su zona específica, en función de que sea una cosa que se está haciendo bien y se quiere recordar para memorizar y/o incluir como buena práctica (+, Plus) o bien una cosa una cosa a mejorar (Δ, Delta).

• • Ponemos los impedimentos, riesgos o cualquier otra cosa crítica que se tenga que ir resolviendo en la zona a tal efecto, especialmente las acciones a realizar que están fuera del alcance del equipo y que sean para el Facilitador (Scrum Master). Los gestionamos de la misma manera que cualquier otra tarea, poniéndolos como pendientes, en curso o hechos.

• Podemos poner en otro color, por ejemplo en azul, los objetivos de la iteración siguiente que iniciamos en la iteración actual, para saber que estamos avanzando, pero también para no perder el foco en que lo primero que tenemos que completar son los comprometidos para la iteración. De esta manera podremos obtener métricas de trabajo avanzado [2] y reflexionar en la retrospectiva.

[Los colores aquí indicados para objetivos de la iteración (ítems del Product Backlog) y para las tareas son orientativos y se pueden ampliar en función de otros aspectos que queramos señalizar de manera especial (ítems de temas diferentes, tareas de corrección de errores, etc.)].

Trucos (sólo si es necesario)

• Utilizar una marca específica para las tareas más prioritarias (reservar el color rojo para indicar problemas o riesgos).
• Poner colores diferentes en función del tipo de tarea (análisis/diseño, construcción, errores).
• Poner 1 punto negro por cada día que una tarea se retrasa, para que el equipo vea si hay algún peligro y para poder reflexionar en la retrospectiva.
• Poner 1 punto naranja cada vez que un objetivo/tarea se reabre por que no pasa las pruebas / control de calidad / aceptación y vuelve «hacia atrás».
• Sólo mover tareas a «Hechas» en la reunión diaria de sincronización, para que todo el mundo sea conciente del avance. Para ello, cuando alguien acaba una tarea, la marca como «hecha» pero no la mueve.
• Una vez acabada una tarea, si es necesario que otra persona haga control de calidad (peer review y/o pruebas), se puede marcar la tarea indicando «Revisar», por ejemplo con un post-it más pequeño. Se puede utilizar el siguiente convenio: un gomet a la izquierda para identificar a quien “hará” y otro a la derecha para identificar a quien “revisará».
  • Notar que la marca «Revisar» es equivalente a tener un estado de tareas (columna) llamado Revisar, por lo que evita crear una “tarea Y” específica para hacer el control de calidad de la “tarea X” o tener una columna específica de “Revisar”, especialmente si este estado no es  aplicable a la mayoría de tareas. Sin embargo, se podría utilizar alguno de estos sistemas de control si se considera necesario, por ejemplo si el 80% de las tareas necesita revisión.
• Poner un número en las tareas para indicar el orden.
• Poner en las tareas el ID o nombre abreviado de la historia de usuario (por si se caen).
• Tener una zona de Parking para los siguientes objetivos si no caben en el tablero o para tareas que el equipo va detectando que sería necesario hacer antes de finalizar la iteración pero que todavía no han sido clasificadas en objetivos.

Material para trabajar con el taskboard

A continuación aparece el material utilizado para crear este taskboard pequeño realizado en cartón pluma. Idealmente, el equipo debería de disponer de una superficie el doble de grande (para poderse ver y leer bien a cierta distancia) y entonces utilizar formatos de post-it  algo mayores.

• Post-its rectangulares: 13 x 7,5 cm,
  • 2 paquetes color amarillo
  • 1 paquetes color azul (o verde)
  • 1 paquete color rosa (o naranja)
• Post-its cuadrados, 7,5 x 7,5 cm, a ser posible: super sticky
  • 4 paquetes color amarillo
  • 2 paquetes color verde
  • 2 paquetes color naranja
  • 1 paquete color lila
  • 1 paquete color rosa (o rojo)
  • 1 paquete color azul
• Post-its pequeños 5 x 4 Etiquetas post-its (2,5 x 7 cm), en 2 o 3 colores diferentes.
  • 6 paquetes color amarillo.
  • 1 paquete color rosa (o naranja)
  • 1 paquete color azul (o verde)
• Cinta adhesiva transparente.
• Cinta adhesiva  de color o negra, 3M Temflex 1500 o TESA 4204.
• Tijeras.
• Gomets pequeños para asignación de 7 personas: 7 colores + rojo = 8 colores. Si es un tablero de corcho: marcas/papelitos de colores y chinchetas.
• Rotuladores normales: negro, rojo, verde, azul.
• Rotuladores de pizarra blanca: negro, rojo, verde, azul.
• Borrador de pizarra blanca.
• Caja donde guardar todo el material anterior.

Agradecimientos

Me gustaría agradecer a las siguientes personas las ideas y consejos que me han ido proporcionando en estos años de uso de tableros de Scrum:

• • [1] Ángel Medinilla, por la sugerencia de utilizar cartón pluma como base.

• • [2] Jordi Salvat y Alabart, por su artículo de métricas en Scrum en que explica el marcaje especial de las tareas no identificadas en la reunión de planificación de iteración.

• [3] Xavier Quesada, por la fuente de recursos e inspiración que es su Visual Management Blog (en inglés), donde aparecen más ejemplos como el siguiente: