Ambos gráficos, el Burn–down y el Burn-up, son muy típicos en la gestión de proyectos ágiles, normalmente con Scrum. Son una herramienta clave para ver el avance, el seguimiento y hacer una previsión de trabajo completado en el tiempo.
Los dos son un gráfico que muestra la cantidad de trabajo en el eje vertical, cuantificado, normalmente, en puntos de historia, pero también hay quien lo hace en número de historias de usuario (opción más difícil porque no todas las tareas son iguales), etc., y el tiempo en el eje horizontal, medido en semanas o, normalmente, en Sprint.
El Burn–down y el Burn-up son similares, se basan en la idea anterior, si bien no son exactamente iguales. Vamos con ello…
El gráfico Burn–down
En el Burn–down se marca el trabajo que está pendiente de hacer, los puntos historia para una Release (te recuerdo aquello del Roadmap ágil: Usando un “roadmap” en un proyecto ágil), por ejemplo, 45 puntos historia. Y, habitualmente, al final del Sprint, se actualiza el gráfico con el trabajo completado. Así la gráfica va bajando.
El objetivo es llegar al eje de las X. La pendiente de la curva ayuda a ver la velocidad del equipo y permite al Producto Owner hacer previsiones.
Gráfico Burn-up
El gráfico Burn-up es, como comentaba, muy similar. Pero con la diferencia se parte del cero, y se va marcando la cantidad de trabajo completado al final del Sprint, por ello la curva va hacia arriba, no hacia abajo.
En la figura de abajo, la línea verde es el objetivo y la gráfica va hacia arriba.
La diferencia entre el Burn–down y Burn-up
Bueno, teniendo en cuenta que son muy similares, más allá de lo obvio, ¿cuál es la diferencia?
Principalmente, se observa cuando el alcance del proyecto cambia (o el alcance de una reléase cambia), es decir, se aumenta el número de historias de usuario, aumenta el número de puntos historia (o baja, pero eso es raro).
En un burn-down es más difícil de gestionar esos cambios de alcance (cosa perfectamente aceptable en un proyecto ágil, recuerda aquello de Responding to change over following a plan). Si aumenta el trabajo realizado, en un burn-down quedaría algo como lo de la figura de abajo. Queda raro, ¿más trabajo añadido? ¿trabajo “deshecho”? ¿Qué ha pasado ahí? Queda Raro.
Sin embargo, con un gráfico burn-up queda visuallmente m´sa claro. En el siguiente la línea verde marca los cambios de alcance.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Hola,
Una consulta, cuando te referies a «trabajo completado» sería la HU analizada, estimada, codificada, implementada, probada y deployada en los ambientes que sean necesarios?
Gracias.
Típicamente sí. Depende también de tu DoD. Terminada y lista para poder pasar a producción. En pre o producción. El deployment ya es decisión del PO
Buen día,
Quisiera preguntarles, quién hace el Burndown Chart? Es responsabilidad del Producto Owner o DEV Team?
Gracias
Si te refieres a los puntos de historia realizados dentro del sprint, es el equipo de desarrollo (responsable de medir su velocidad).
Si te refieres a los puntos de historia realizados sprint a sprint, es el Product Owner (responsable de saber cuando estará listo nuestro producto y reportar avance a los intereados)
sprint burndown -> dev team (medir su propia velocidad)
release burndown -> PO (Comunicar avances a interesados)
Lo puede ir completando el scrum máster al final de cada Daily.
Hola Javier, ¿Que herramientas o plantillas excel existen en el mercado Opensource y son más usadas para hacer la gestión de burn down, up, HUs, sprint backlog, product backlog, etc?