¿Hay que usar tableros visuales en Scrum? Técnicamente no, de hecho sabemos que es un tema ciertamente polémico. Es curioso que los agilistas de los que mejor referencia tengo siempre se van a lo visual y como los más juniors o con más afán por el control personal tiran por los digitales.
Técnicamente vale cualquier cosa, de hecho, que el propio Development Team decida qué tipo de tablero elegir. Los que me conocen saben que allá donde voy trato de proponer siempre tableros visuales. En una consultora en la que estuve mucho tiempo cuando llegué sólo había un equipo con tableros y cuando me fui muchos equipos habían decidido animarse a utilizarlo, ahora es casi un “estándar” en la organización. Y en otras organizaciones donde he participado casi siempre les hemos propuesto a los equipos un tablero visual. Cuando estudiamos el Professional Scrum Master II los trainers decían que los equipos más maduros llevan a lo visual toda la información. Quizás este sea el camino para equipos maduros, pero como todo, recordemos que las herramientas no son la clave, son las personas y el mindset con el que trabajamos lo que marca la diferencia.
Dado que no puedo poner fotos porque son privadas de cada equipo, os muestro algunos esquemas que hemos utilizado por si os sirve de inspiración. Si tenéis ideas compartidlas 🙂 que así aprendemos tod@s.
¡Veamos ejemplos!
Patrón TODO-DOING-DONE
Este es el más clásico de los tableros, con las columnas todo-doing-done. Este tablero, para mí, es muy desaconsejable porque realmente asume que todo el mundo hace de todo ya que la regla es que, cuando no tienes nada que hacer, asumes la primera tarea libre. Aunque he tenido la experiencia de trabajar en equipos así, cada vez es menos común que ocurra con la cantidad de nuevos frameworks que aparecen en las diferentes capas que hoy en día componen un producto digital. Por tanto, es un tablero en el que cuesta organizarse aunque en equipos poco maduros no aporta mucho.
Si es cierto, que este tipo de tableros fomentan la “responsabilidad compartida” y es un concepto que no debemos de perder en Scrum.
Patrón TODO-DOING-TEST-DONE
Este modelo es otro clásico que podemos ver en muchos equipos. Añadir una columna para los diferentes estados como puede ser “test” o por ejemplo “integración” o “pre producción”. Esto nos permite explicitar los estados por los que pasan cada PBI que queremos trabajar. El problema de este tipo de tableros es que fomentan la especialidad y eso puede llevarnos a que los miembros del Development Team no actúen como equipo.
Patrón Persona-Día
Este es otro patrón que podemos utilizar muy útil sobre todo con equipos nuevos que aún no se conocen. Consiste en poner los miembros del equipo y los días del Sprint. Tratamos de llenar esos días. Se que la primer impresión puede parecer de un excel en la pared, pero ayuda mucho a entender que en una planning lo que vamos a hacer es planificar y no solo hacer estimaciones constantemente.
Vemos cómo funciona:
- Cuando una tarea ocupe más de un día (o eso creamos lo ponemos) así hacemos una previsión.
- Podemos usar colores diferentes por tipo de tarea, en este caso rojo para servicios y naranja para la parte frontal.
- Si un compañero va a estar de vacaciones pues lo podemos marcar para no llenarlo.
- Si hay un día que no trabajamos lo marcamos con una “X”.
A mi este patrón me gusta mucho porque nos permite hacernos una idea temporal sin hacer una estimación que nos lleve muchas horas y dolores de cabeza. Ideal para equipos que se acaban de iniciar en esto. Si tienes un equipo que tiene un gran hito a mitad de Sprint nos puede servir para identificar todo lo que hay que tener en ese hito hecho y así evitar que nos quedemos cosas sin hacer.
La parte mala de este modelo es que es una estimación por días (que quizás no es la mejor) y también la relación entre tareas. Si tenemos una historia dividida entre varias tareas es complicado enlazarlas.
Lo mejor de este tablero es el seguimiento por parte del Development Team. Cada día debemos de liberar el día anterior y rehacer el tablero si no hemos acabado. Por ejemplo, en la Daily Scrum del martes la columna primera debe estar sin postits, si hay cosas sin terminar habrá que dejar todo terminado.
Patrón Semana
Este es, con diferencia, mi tablero favorito. Suelo proponerlo con equipos que ya tienen un poquito de madurez y han pasado del patrón diario. Con este diseño lo que hacemos es trabajar por semanas, con lo que nos hacemos una idea temporal de lo que seremos capaces de hacer. De hecho, a la hora de construirlo, hacemos la pregunta ¿Hasta dónde llegaremos esta semana? ¡Y a pensar!
Cada postit amarillo es un PBI, mientras que las verdes son tareas del amarillo. En este ejemplo no significan mucho los colores. Con las flechas marcamos dos ideas, por un lado el Sprint Goal que nos permite identificar la cantidad de PBIs que nos harían cumplirlo.
Por otro lado, la flecha DoD nos sirve para saber cómo vamos. Esa flecha solo avanza si hemos terminado todas las tareas de un PBI concreto. Es una manera muy buena de focalizar al equipo en acabar cosas.
A la hora de marcar como vamos podemos hacer varias cosas:
Podemos darle la vuelta al postit, así marcamos que está hecho. Otra opción es una pegatina de color o una marca como puede ser un check. Cuanto más llamativo más nos permite saber el estado del tablero.
Opciones con colores
Podemos hacer multitud de cosas usando los diferentes colores de los postits.
Hay equipos que utilizan el amarillo para marcar los PBIs o las tareas típicas del Sprint y el verde u otro color para incidencias. Un ejemplo que he visto reciente es usar un color para las tareas del goal y otras para las extra, así sabemos donde poner el foco.
Otra opción es cuando damos servicios a varias aplicaciones o varios módulos. Para eso, podemos crear una leyenda con módulos y colores para saber a qué nos estamos dedicando. Además, si a una aplicación ya no le vamos a dar servicio, podemos eliminar la descripción y poner otra. Lo malo de este tipo de tableros es que no suele haber muchos colores de post its diferentes.
Por último, con colores podemos marcar bloqueos, generalmente se usa el color rosa porque es más llamativo. Generalmente se pone encima y se escribe el problema a resolver, incluso podemos añadir el nombre de la persona que lo va a resolver o que lo está trabajando.
Otros punto de información.
Podemos añadir otros radiadores de información a nuestro tablero que nos permitan saber cómo estamos actualmente. Voy a comentar los principales.
Es bastante típico poner a un lado el Burndown Chart, hecho a mano o digital. Hay equipos que han probado hacerlo con globos, cada PBI es un globo y si está terminado se pincha en la Daily Scrum.
Otro panel típico de información son las reglas de equipo, a veces creadas en momentos iniciales a veces rellenadas a base de retrospectivas. Las reglas de equipo nos recuerdan quienes somos y qué comportamientos son los esperados por los miembros de este equipo. Hace poco estuve con un equipo que definió tus propios valores, otros optan por poner los valores de Scrum visibles.
La Definition of Done (DoD) es otro clásico a tener presente en nuestro tablero. Aunque, en este caso, es bastante habitual que haya una copia en cada mesa de trabajo, recordemos que la DoD nos dice cómo trabajamos y es esencial tenerlo presente.
Tener presente el Sprint Goal también es importante sobre todo en la Daily Scrum. Recordemos que el evento gira en torno a ello y por eso nos viene bien recordar el motivo por el que hacemos este Sprint.
Por último, la visión de producto debería estar también visible. La visión no es un artefacto obligatorio de Scrum, pero muy recomendable sobre todo en la toma de decisiones.
Jira no permite esto…
Lo bueno de los tableros físicos es que, nos permite imaginarnos mil y una posibilidades. Jira, nos limita, de hecho, el tablero que usa es el que precisamente menos recomendamos. A pesar de la trazabilidad que un tablero digital permite, el físico nos permite el aquí y el ahora, fomenta el foco y la transparencia sobre el trabajo del Sprint.
Más adelante ilustraremos más ejemplos visuales que podemos utilizar con nuestros equipos 🙂
