Gráfico de Burn-Up
El Gráfico de Burn-Up en Scrum muestra cuánto avanzó el equipo hasta el momento, cuántos puntos llegó a quemar hasta el último Sprint, en relación al esfuerzo total necesario para terminar el proyecto.
Sobre el eje horizontal se ubican los Sprint, sobre el eje vertical se ubican los puntos de historia.
El Gráfico de Burn-Up se complementa con el Gráfico de Burn-Down (que muestra cuánto le falta al equipo para terminar el Sprint en curso).
Análisis
El Gráfico de Burn-Up muestra, iteración a iteración, el avance del equipo en relación al proyecto total.
Al inicio se estiman las historias que el Dueño Del Producto tiene, con lo cual se establece el "techo" del burn-up (la línea punteada horizontal). Sabiendo el factor de foco del equipo y su cantidad de integrantes podemos saber su velocidad (cuántos puntos quemarán en cada sprint). Con estos datos se puede trazar la "línea de quemado ideal" (la línea diagonal naranja), la cual indica el avance ideal para llegar a quemar todos los puntos del proyecto. De aquí se deriva la cantidad de sprints que necesitará el equipo para terminar el proyecto.
Al finalizar cada Sprint el equipo sabe cuántos puntos pudo quemar en esa iteración, y va acumulando este valor en el gráfico (es decir, va "quemando" puntos, representada por la línea negra). De esta manera, se puede ver rápidamente el progreso del equipo en relación a la totalidad del proyecto.
Consejos
- No se debe estimar sprints, sino que historias. Entonces, previo al comienzo del proyecto, el Dueño Del Producto tiene que preparar historias para todo el proyecto (se entiende que no tienen que ser tal cual van a quedar, ya que es todo un acercamiento a fecha y no un compromiso).
- Una vez estimadas todas las historias con tarjetas entre todos los miembros del proyecto, se obtiene un número (por ej: 45 puntos de historia).
- Se calcula la velocidad del equipo, tomando en cuenta cuantos van a desarrollar y bajo que factor de foco (estimado). Por ej, en un proyecto con dos desarrolladores al 100% y con FF de 50%, la velocidad sería 10.
- Se realiza un gráfico trazando como techo el alcance del proyecto (45 puntos), y como limite X , 5 sprints (se redondea para arriba).
- Ante cambios de alcance, de Factor de Foco, etc, se debe actualizar el gráfico.
- Con el paso de los sprints, cualquiera podrá ver claramente si el equipo llega al dimensionamiento, o con tiempo de anticipación, se puede anticipar que no se va a llegar.
- En el caso que no se pueda "correr" la fecha, se podrían tomar medidas (por ej, agregar mas gente, aunque esto no siempre acelera) para llegar.
- El equipo puede armar un check list, con cosas a tener en cuenta a la hora de dimensionar (ejemplo: objetos de negocio, DAO, comunicación con sistemas externos, técnias de Behavior Driven Development, Diseño, Análisis, Selenium, Documentación, etc). Esto pasa a formar parte de la Definicion De Terminado.
- Se podría poner en el gráfico, que factor de foco se tomó para hacer el dimensionamiento. Con este dato, el gráfico y haciendo un par de números se pueden obtener los demas datos (por ejemplo, la velocidad del equipo).
- Los cambios de alcance, en vez de ser reflejados con otra línea punteada como techo, podrían ser mostrados como una suba de la línea original (Imaginense un escalón, y sino preguntenme y se los dibujo). Con esto se ve claramente cuando cambió el alcance.
- En el caso de tener que entregar releases en alguna fecha, se pueden marcar en el eje X con una R (Por ej, en el sprint 3 y 5 ponemos una R)
