¿Qué es y cómo hacer un diagrama de Burndown?

Un diagrama de Burndown (o ‘de trabajo pendiente’) es una de las herramientas que proporciona Scrum que me parecen más útiles. De hecho es una herramienta que aunque tiene mucho sentido si estás aplicando una metodología de desarrollo ágil, también se puede aplicar en otros contextos.
 

¿Qué es un diagrama de Burndown?

El diagrama de Burndown sirve para saber el tiempo que falta para completar el trabajo. Normalmente se utiliza para saber cuánto falta para terminar las historias comprometidas en un sprint.

 
En la práctica es un diagrama de dos ejes, en el eje X el tiempo en días de duración del sprint (o iteración) en el eje Y la cantidad de trabajo comprometida con el cliente durante el sprint, en las unidades que se hayan acordado (por ejemplo días ideales)
 

¿Por qué usar un diagrama de Burndown?

 
Los diagramas de burndown me parecen muy útiles por 3 motivos:
 

1. Te ayudan a poder responder la pregunta clave: ¿cuánto falta para terminar?

2. Son visuales: Cualquier que vea un diagrama de este tipo lo entiende

3. No cuestan nada de mantener: Actualizar el diagrama es tan sencillo como sumar el número de días ideales que quedan tras el día anterior y trazar una línea.

Además, si utilizas el diagrama de Burndown fuera de Scrum, indirectamente te obliga a seguir ciertas prácticas ágiles o rutinas que te van a ayudar a planificar mejor tu proyecto:

1. Para empezar te obliga a dividir el trabajo en iteraciones.

2. Además te obliga a cuantificar el trabajo que hay que hacer, es decir, dividir el trabajo en tareas y estimar su duración.

3. Por último, te obliga a hacer un seguimiento diario del progreso del proyecto.

¿Cómo hacer el diagrama de Burndown?

Si no estás aplicando Scrum u otra metodología ágil, puedes usar un diagrama de Burndown igualmente y necesitarás antes de hacerlo estos pre-requisitos.

1. Acuerda con tu cliente dividir el trabajo en iteraciones, una iteración es un ciclo de desarrollo en el que te comprometes a desarrollar cierta funcionalidad.

2. Estima las tareas a desarrollar en días ideales con la técnica que suelas utilizar (estimación póker, juicio de expertos, sacando la bola de cristal, diciendo un número al azar…)

3. Según el equipo que vaya a trabajar en el proyecto y la duración del sprint, acuerda la funcionalidad que vas a desarrollar.

Por ejemplo, si en el proyecto van a trabajar 3 personas durante 15 días. Puedes comprometerte a desarrollar funcionalidad equivalente a 45 días ideales.

Con esa información ya puedes dibujar el diagrama de Burndown. Puede que haya por ahí diagramas online o colaborativos, pero puesto que es tan sumamente sencillo actualizar este tipo de diagramas, mi recomendación es que utilices un soporte físico y que esté bien visible por todos los miembros del equipo para que todos (o cualquiera que pase por ahí) sepan el estado actual del proyecto.

Hay una web que te facilita aún más las cosas: https://www.burndowngenerator.com/

Generar el diagrama de burndown es tan sencillo como introducir el número de días ideales, la duración de la iteración y ponerle un título. La herramienta nos crea el diagrama con los dos ejes y una línea recta que muestra la velocidad ideal de desarrollo.

Protip: Si como título del diagrama, pones el objetivo general de la iteración y la fecha de entrega, todo el mundo estará más enfocado y cualquiera entenderá el contexto del diagrama.

A partir de ahí, lo único que tenemos que hacer cada día es reunir al equipo, para que actualicen el estado de sus tareas indicando cuánto les queda para terminar la tarea que tienen en curso. Sumar el total de días y actualizar la gráfica.

Siempre que vayamos por debajo de la línea quiere decir que llegamos a tiempo, si vamos por encima de la línea puede querer decir varias cosas: que hemos estimado mal, que ha habido algún problema bloqueante, alguna baja, que el equipo no está a la altura, muchos cambios en los requisitos…

En cualquier caso, lo bueno de mantener el diagrama de Burndown actualizado es que permite reaccionar pronto y poner solución a cualquier problema que haya surgido.

Una vez termine la iteración, se repite el proceso pero con una gran ventaja. Ahora ya tenemos una referencia de la velocidad del equipo o cierta experiencia a la hora de estimar, atacar cambios, etc. y seguro que cada vez nos cuesta menos ajustar la cantidad de funcionalidad que se puede desarrollar por iteración y todos somos mucho más felices.

Un par de ejemplos de diagramas de Burndown

 
Por último un par de ejemplos de diagramas de Burndown de dos iteraciones.
 
En el primero el compromiso era desarrollar funcionalidad relacionada con un carrito de la compra equivalente a 45 días ideales de trabajo. La duración del sprint era de 15 días.
 
En general, la línea de trabajo pendiente (línea roja) fue siempre por encima de la velocidad ideal de desarrollo (línea negra) y al final de la iteración no se completaron todas las historias comprometidas.
 

 
En el segundo ejemplo, tras la experiencia anterior, lo que se decidió fue comprometer menos historias de la gestión de productos, equivalentes a 40 días ideales de desarrollo, la duración del sprint fue la misma.
 
El resultado fue que se completaron todas las historias, incluso se terminó un día antes.