Pages Menu
Categories Menu

Posted by on Dic 17, 2013 in General | 6 comments

Gráficos Burn–down vs Burn-up para el seguimiento de un proyecto ágil

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.

burndown

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.

burnup

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.

burndown2Sin embargo, con un gráfico burn-up queda visuallmente m´sa claro. En el siguiente la línea verde marca los cambios de alcance.

burnup2

 

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

6 Comments

  1. 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

  2. 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)

  3. Lo puede ir completando el scrum máster al final de cada Daily.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This