Post publicado también en el blog de Kaleidos
Entre los usuarios de Taiga y soporte, suelen surgir debates y preguntas muy interesantes sobre cómo usar la herramienta y si encaja o no con la filosofía y objetivos del producto.
Os traigo hoy uno sobre control del avance del sprint:
«La gráfica actual del sprint (Sprint Burndown Chart en Taiga) no nos vale porque solo aparecen los puntos quemados cuando se cierran todas las tareas de una User Story con lo cual durante la primera semana del sprint da la impresión de que no se ha avanzado nada, aunque se vayan cerrando tareas de las diferentes User stories.
Los requerimientos que tenemos del scrum master es trabajar con la filosofía de tarea como medida de lo que hace el equipo y avance real (incluso trabajan con horas)»
Este Scrum Master, sigue el libro. La guía oficial de Scrum en su sección de Sprint Backlog habla de:
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
Un desarrollo más en profundidad muy conocido es como lo cuenta Henrik Kniberg en su libro «Scrum desde las trincheras» (aquí original) y también habla de contabilizar el trabajo pendiente del sprint.
En los dos casos hablan de preguntar al equipo cuánto trabajo cree que les queda pendiente de cada historia, sea en puntos, sea en horas, sumarlo y ver lo que queda.
Lo que es propio de la implementación que hace este equipo, es contabilizar el avance sumando las horas de las tareas que se han terminado.
El avance de las tareas en una historia no te da información real del avance del sprint, porque si somos fieles a Scrum, en la demo solo se pueden mostrar historias terminadas, no ‘casi’ terminadas.
Una gráfica de tareas pendientes en el sprint que muestra que estamos al 90% de sprint terminado, pero realmente solo tenemos 2 de 8 historias terminadas (25%), puede dar una falsa sensación de tranquilidad. Y evita algo muy importante, que es centrarse en terminar historias.
Además de esto, llevar el control por tareas, y además en horas, hace que haya que estimarlas al inicio del sprint con el correspondiente esfuerzo.
Y el problema de calcular el ‘quemado’ del sprint a partir de una estimación inicial, es que no contempla los cambios y problemas que nos vayamos encontrando. Y si la solución es reestimar las tareas si ‘explotan’, solo hace aumentar la burocracia.
Cuando allá por el 2010 intentamos una aproximación fiel contando las horas pendientes en el sprint, enseguida nos dimos cuenta que era una microgestión que aportaba poca información que no nos diera ya el panel. Los bloqueos que puedas tener en una historia se pueden detectar igual en el daily: «Llevas tres días con esta historia de 2 puntos. Hay algún problema?» , es mucho más efectivo.
En mi opinión, si se quiere tener una gráfica de «Sprint Burndown» con más detalle que la actual de Taiga, haría como recomienda la literatura, preguntando al equipo en el daily «¿Cuántas horas calculas que te quedan de tu historia?». Es mucho más realista y no depende de tareas terminadas. Y con esa información haría una gráfica para colgar en el tablón o en un doc compartido.
Si se quiere automatizar, en la versión liberada esta semana de Taiga, se puede crear un custom field para ir poniendo esa cantidad de horas pendientes en ese campo y se podrá sacar una gráfica de manera fácil.
Tema muy interesante, sin duda. Volveremos sobre el control detallado de los tiempos, internamente llamado «El dilema del Time-Tracking», en otras preguntas que nos hacen.
lifetime.day.each() { enjoy() } 