Ejemplo de uso del tablero o pizarra de

tareas (Scrum Taskboard)

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: