Hoy revisaremos una parte que aunque no está explicitada la utilización directamente en la guía de Scrum está implementada en la mayoría de los equipos que utilizan Scrum. Se trata del tablero Kanban , también conocido como el sitio donde los agilistas ponen los postit :)
Los tableros Kanban están muy extendidos y aceptado por los equipos Scrum siendo un elemento de transparencia e inspección que se convierte en una herramienta muy potente si sabes hacer uso de ella. Tenéis que tener en cuenta que el Kanban utilizado en Scrum es una versión reducida y adaptada con la intención de que los dos se complementen formando un tándem muy poderoso.
Recordad que la unión hace la fuerza ( siempre que se tenga un objetivo común o un buen Sprint Goal 😛 )
Os dejo el link a la guía Kanban para Scrum.
Con la intención de engancharos a Kanban (desde la visión de Scrum) te resumo en unas líneas y de manera muy general los beneficios y mas abajo (para los mas cafeteros ) entro de manera mas técnica aportando datos:
Kanban ayuda en todos los eventos de Scrum, aportando motivos de conversaciones en la Daily para tomar consciencia del estado real del sprint. Aporta conocimiento sobre la capacidad de trabajo del equipo en la Planning. Ayuda al Producto Owner en la review quitando incertidumbre y poder estimar el alcance de la próxima entrega de valor. Entrega información para poder motivar al equipo con la mejora o encontrando los “pain points” en la retrospectiva para evolucionar en la mejora continua de todo el equipo Scrum.
Ahora sí, esta parte es mas técnica y la intención es en próximos posts explicaros que son cada una de las partes así como el funcionamiento del tablero.
Kanban en los diferentes eventos de Scrum:
- Sprint Planning
- Kanban ayuda entregando métricas del Flow de sprints anteriores y así ayuda a todo el equipo Scrum a entender su capacidad de trabajo, siendo este un valor clave para la planificación del siguiente Sprint. ¿Cuánto valor podemos entregar en un Sprint?, ¿Cuántos PBI (Tareas, Historias de usuarios, casos de uso, etc…) podemos incorporar al Sprint Backlog?
- Daily Scrum
- Es un gran generador de conversaciones sobre el estado real del trabajo involucrando a todos los Developers y haciéndoles reflexionar sobre el camino hacia el Sprint Goal.
- ¿Cuantos ítems tenemos bloqueados y que podemos hacer para desbloquearlos?
- ¿Qué ítems están yendo mas lentos de lo esperado?
- ¿Cuál es el “work ítem Age” de cada uno de los ítems?
- ¿Están representados todos los estados en la tabla o es necesario algún nuevo estado que impacta en nuestro trabajo?
- ¿Tenemos algún cuello de botella? ¿Cual es el impedimento? (WIP)
- ¿Se cumple el SLE (Service level Expectation) o hay elementos que lo transgreden? ¿Qué se puede hacer para arreglarlo?
- ¿Nuestro “cycle time” es el proyectado?
- Sprint Review
- Las métricas pueden crear oportunidades de conversación y proveer de información adicional al Product Owner para priorización de Product Backlog así como para estimación de próximas entregas de valor.
- Retrospectiva
- Las métricas aportadas sirven para motivar al equipo revisando la evolución del “average cycle of time” , “average througput” y del WIP del equipo utilizando el “cumulative flow diagram”).
- Podemos definir mejoras en el tablero para mejorar en el entendimiento del equipo:
- ¿es necesaria la utilización de “políticas”?
- ¿Es necesaria la utilización de “Clases de servicio”?
- Viendo la evolución de las métricas podemos saber si el equipo está en un estado de mejora.
Por hoy me despido y espero haber sido capaz de transmitir un poco de la potencia de Kanban.
Como siempre ¡sed curiosos! Y hasta pronto.
