¿Para qué leches quiero yo un tablero lleno de post-it? Esto fue lo primero que pensamos en el equipo, y como somos unos kamikaze empezamos sin tablero. Total ya teníamos JIRA, como excusa nos venía al pelo, cuando lo cierto es que nos daba algo de vergüenza saber que íbamos a estar de paseos con el tablero de un lado a otro.
El primer día que el Product Owner (o sea yo) se empeñó en montar el tablero, y empezar a usarlo, nos dimos cuenta de la potencia del mismo. Y el primer comentario fue: "Madre de dios, nos hemos pasado planificando". Nuestra columna de "To Do" estaba cubierta de arriba a abajo de post-it con tareas técnicas, y ya llevábamos medio Sprint consumido.
Es cierto que las herramientas como JIRA ayudan a tener controlado todo el proyecto, poder ir haciendo seguimiento de los cambios, generar un Burn Down del Sprint, sacar algún informe o gráfico, pero no tiene la presencia visual del Tablero. Quizás no sepas de que va el proyecto, pero cualquiera se pone delante de un Tablero donde esté planificado el Sprint, y tienes claro la cantidad de trabajo pendiente, en curso, y realizado de un solo vistazo.
Por medio de post-it más pequeños con los nombres de cada persona del equipo Scrum puedes saber quién está con cada tarea y se puede controlar, de una forma muy simple, cuantas tareas puede tener asignada una persona a la vez. Para realizar las Dayli es fundamental, en seguida se ve y actualiza el trabajo realizado cada día, lo que queda pendiente, si hay impedimentos que paren o bloqueen una tarea, y muchas más cosas que no fuimos conscientes hasta que empezamos a usarlo.
Lo malo es que ahora los bandarras de nuestro equipo no me actualizan el estado en JIRA...
Aparte de la visión del Sprint, se puede utilizar para tener información adicional a mano. En nuestro caso para las dependencias con terceros que aún tenemos pendientes, y acciones que hayan salido de la Retro, principalmente. También tenemos el DoR y el DoD, pero la verdad que no le hacemos ni caso a esos 2 post-it (voy a arder en la hoguera para sacrílegos de Agile por esta frase).
Esta es una foto de nuestro tablero tras finalizar un Sprint del primer Program Increment:
En uno de los Item Backlog tuvimos un montón de trabajo extra y se nos acumularon un poco. La teoría del equipo (con 1 voto en contra) es que el experto en Google Analitics cobra por post-it y ese Sprint comió caviar iraní todos los días.
Por la parte la otra cara del Tablero tenemos el Product Backlog no planificado, y el Sprint Backlog previsto para cada Sprint tras la última Planificación de PI:
- Verde: Epics del Proyecto
- Azul: User Story o Product Item Backlog. Llevan además el número de la Epic a la que pertecen (abajo izquieda) y la estimación (abajo derecha).
- Fusia: US o PIB a refinar y dividir en otras más pequeñas.
- Naranja: Dependencias con terceros que afectan a US de la Epic
- Amarillas: Tareas técnicas de cada US o PIB.
En resumen, el Tablero es una de las mejores herramientas para hacer Agile, que se complementa perfectamente con aplicaciones de seguimiento y gestión.
No hay comentarios:
Publicar un comentario