Durante el desarrollo de un proyecto en Scrum, el equipo se compromete a entregar un producto en una fecha determinada. Teniendo en cuenta que la estimación no es 100% precisa y a fin de elaborar un plan de acción en caso de que haya graves retrasos, el equipo debe tener una herramienta para poder evaluar cómo progresa el desarrollo en función del tiempo disponible. Entonces ¿cómo medimos si estamos con tiempo de sobra o si no estamos llegando con lo comprometido a la Sprint Review o si estamos llegando bien a la fecha de entrega del proyecto?

El Burn-up y Burn-down son la respuesta a estas preguntas.

Para este artículo vamos a presentar un proyecto de ejemplo, sin centrarnos en para qué es ni para quién, sino en cuánto tiempo estimamos que insumirá su desarrollo. Está estimación resultó ser de 5 Sprints en total, haciendo 500 puntos en cada Sprint.

Ahora supongamos que estamos en el inicio del segundo Sprint y nosotros, en equipo, nos comprometemos a desarrollar 3 historias durante los siguientes 10 días.

Al inicio empezamos confiados, comenzamos a diseñar nuestra solución para la primera historia, debatimos, generamos ideas, creamos una solución y empezamos a escribir código, nos trabamos con los diversos problemas o nos ocupamos con nuestros compromisos del día a día hasta que, en el medio del Sprint, durante un Daily Scrum, nos preguntamos: ¿Llegaremos? ¿Cuánto hicimos de lo que nos propusimos?

Claramente, si no tenemos las tareas estimadas la pregunta a responder es mucho menos precisa, y aún con la estimación hecha, la solución no es tan explícita sin una representación gráfica del proceso. En este momento, un burn-down puede ayudarnos a resolver este problema.

El burn-down

El burn-down es un gráfico de 2 ejes, X e Y, comúnmente utilizado en Scrum donde llevamos el registro de los puntos de estimación de las tareas que tenemos que desarrollar en todas las historias a la que nos comprometimos. Debajo podemos apreciar un ejemplo de burn-down:

Como se aprecia en la imagen, en el eje X, se miden todos los días del Sprint durante los que estaremos trabajando en el desarrollo (10 días en este caso), y en el eje Y, los puntos de tareas que debemos desarrollar para completar el compromiso. Habiendo estimado todas nuestras tareas, tenemos un total de 12 puntos. Además, en este gráfico dibujamos una línea de tendencia que va desde el día 0, con 12 puntos, hasta el último día, sin puntos. En nuestro ejemplo es la recta azul.

Esta línea nos va a servir para poder medir nuestro progreso y si estamos avanzando lo suficiente para poder cumplir nuestro compromiso como equipo de desarrollo durante el Sprint actual. Mientras van pasando los días, luego de cada Daily Scrum, marcamos en nuestro Burn-down una recta que va desde el día anterior en el eje X hasta el día actual, marcando en el eje Y el total de puntos restantes a quemar (tanto pendientes como aquellos que se estén aún trabajando).

Si nuestra línea de progreso se ve por encima de la línea de tendencia, significa que no pudimos avanzar mucho ese día del Sprint. En el caso de la imagen que tenemos arriba, en el primer día hubo un avance un poco lento pero luego pudimos sobrellevarlo, haciendo que nuestra línea de progreso este por debajo de la línea de tendencia y nos indique que estamos avanzando a una buena velocidad.

Suponiendo que en el siguiente Sprint casualmente tengamos 12 puntos en total, y sin haber hecho nada el primer día (el equipo no pudo desarrollar ni diseñar nada por impedimentos, compromisos, etc.) El burn-down, al día siguiente, quedaría así:

En el caso de que hayamos podido, por ejemplo, hacer un diseño que estimamos en 2 puntos, el burn-down, en el día siguiente, quedaría así:

 

 

Por lo que podemos ver con estos avances, por ahora estamos avanzando a una velocidad baja.

En caso de que estemos al día 8 y aún queda mucho por hacer, como vemos aquí:

 ¿Qué hacemos ante este caso? Podemos realizar los puntos restantes en el día 9, lo cual no siempre es posible, por lo que deberemos avisarle a nuestro Product Owner que no podremos realizar todo lo que nos propusimos en el Sprint. Luego, en la retrospectiva, el Equipo de Desarrollo y el Scrum Master tienen que revisar qué fue lo que pasó este Sprint dado que no se pudo cumplir esta última historia, y en el próximo también se deberá bajar la velocidad del equipo para poder estimar de manera más eficiente. El equipo puede ofrecer, si lo desea, un resarcimiento al Product Owner, como disculpas por no haber llegado al compromiso.

En el proyecto que estamos desarrollando, al final no pudimos terminar la última historia, de 200 puntos, por lo que hicimos 300 puntos en vez de los 500 que estimamos.

El burn-up

Imaginemos, con el caso anterior, que en los Sprints siguientes logramos llegar con el compromiso de manera justa (500 puntos en cada uno). Normalmente, sus burn-downs reflejarían una velocidad correcta, dado que logramos llegar a 0 en el décimo día en cada uno, pero ¡el proyecto no está terminado!  En el caso de este ejemplo, todavía nos faltaría una historia de 200 puntos. Entonces, ¿cómo vemos que estamos bien con las historias desde el inicio del proyecto hasta la fecha de entrega? Para esto usamos un burn-up.

El burn-up es un gráfico lineal de 2 ejes, similar al burn-down, donde el eje X es la cantidad de Sprints totales del proyecto, y el eje Y representa el total de puntos de las historias (no de sus tareas) del Product Backlog que debemos "quemar". Como en el burn-down, tenemos una velocidad ideal para poder controlar si estamos encaminados para desarrollar lo que nos comprometimos a hacer. 

Este gráfico es útil para el Scrum Master, ya que le permite realizar un análisis macro del estado del proyecto y, en caso de que la velocidad sea baja, investigar si se puede aumentar la velocidad del equipo de desarrollo o arreglar con el Product Owner para modificar la prioridad de las historias y dejar una para la siguiente iteración del proyecto, entre otras posibles decisiones.

Analizando nuestro ejemplo, con 200 puntos aún por desarrollar, el burn-up de nuestro proyecto al llegar a la fecha límite se vería así:

 

En este caso, si el Scrum Master hubiera tenido este gráfico en su poder, el resultado del proyecto hubiera sido distinto, dado que habríamos visto que nos estaban faltando 200 puntos para poder cumplir el compromiso total del proyecto.

Conclusión

Ya vimos 2 herramientas muy útiles para seguir el desarrollo de nuestro proyecto ágil, pero ¿cuál es la diferencia entre ambas?

• El burn-up sirve para medir nuestro proyecto en el largo plazo, ¿cómo estamos para llegar al deadline del proyecto? Mientras que el burn-down nos sirve para medir nuestro proyecto a corto plazo, ¿cómo vamos con el compromiso del Sprint?
• El burn-down mide los puntos estimados de las tareas que conforman nuestras historias de usuario del Sprint Backlog mientras que el burn-up mide los puntos de las historias de usuario del Product Backlog
• El burn-up puede reflejar el alcance del proyecto, es decir, si vamos por encima de la velocidad ideal, el alcance del proyecto fue superior al estimado, por lo que el equipo tiene una velocidad mayor a la que se pensaba o las historias fueron sobreestimadas.
• El burn-down es una herramienta para ayudar al Equipo de Desarrollo mientras que el burn-up es una herramienta para ayudar al Scrum Master (esto no implica que deba ser usado exclusivamente por ellos).