Alíate con las métricas, ¡predice tu progreso en Scrum con las “burn charts”!

Uno de los fundamentos de Scrum es el empirismo y medir la predicción del progreso de un equipo es clave para sostenerse en sus tres pilares clave: inspección, adaptación y transparencia.

Mientras se inspecciona, es posible identificar y corregir variaciones no deseadas durante un Sprint; adaptar sus los procesos y artefactos, ayuda a minimizar esta desviación; y la transparencia implica que estas acciones sean visibles para todos los involucrados: scrum master, product owner y equipo de desarrollo.

Este último dispone de una serie de gráficas de predicción del progreso de los ítems del Product Backlog (PBIs) que cumplen con la definición de “hecho” durante un Sprint.

Hay dos gráficas muy conocidas y extendidas y en las que centraré mi entrada: burn-down charts y burn-up charts.

Ambas son gráficas bidimensionales, donde se refleja en el eje cartesiano ‘x’ la duración del Sprint; y el progreso de PBIs “hechos” y no “hechos” (medidos, por ejemplo, en puntos de historias de usuario o simplemente en número de ítems) en el eje cartesiano ‘y’.

Sé que con esta breve introducción os surgen muchas dudas, por ejemplo ¿cómo funcionan estas gráficas? ¿Cuál de ellas debo utilizar si soy miembro de un equipo de desarrollo de Scrum? ¿Es una mejor que otra?

Os plantearé bondades, similitudes, diferencias y distintos usos de cada gráfica. Después, el trabajo estará en vuestras manos para decidir si os son o no útiles.

Burn-down chart

La gráfica de quemado hacia abajo, o “burn-down chart”, representa la cantidad de trabajo restante en el Sprint. Parte de la totalidad de PBIs y muestra dos tipos de líneas descendentes.

La primera de ellas refleja el progreso actual, es decir, el total restante de PBIs no “hechos” en un momento determinado del Sprint. La segunda, permite visualizar el ideal de progreso. Es, por tanto, una gráfica que destaca por su simplicidad en cuanto a explicación, uso, análisis y actualización diaria.

Estas características hacen que la gráfica burn-down sea una de las más extendidas en Scrum.

Burn-up chart

Por el contrario, la gráfica de quemado hacia arriba, o “burn-up chart”, indica la cantidad de trabajo acumulado ya “hecho”. Muestra información relativa al progreso desde el primer Sprint, cuando aún no hay PBIs “quemados”.

Este tipo de gráfica incluye tres líneas ascendentes: las dos primeras son similares a las de la gráfica burn-down y la última indica el alcance en la medida elegida para los PBIs.

Mucha teoría, un ejemplo práctico por favor

Como no es lo mismo contarlo que vivirlo, me gustaría mostraros lo explicado con un ejemplo. Imaginemos el siguiente escenario: proyecto Scrum con una longitud de Sprint de 3 semanas y una predicción del alcance para el Sprint 1 de 200 PBIs, medidos simplemente en número de ítems. Es el día 5.

Una situación totalmente real para la gráfica burn-down del progreso del Sprint tras 5 días podría ser la siguiente: 147 PBIs restantes según el progreso actual de desarrollo y representados por la línea roja, frente a los PBIs ideales que podrían estar “hechos”, 133, representados por la línea azul.

Análogamente, si se aplica el mismo escenario, pero para la gráfica burn-up, se puede apreciar la cantidad de PBIs “hechos” con la línea roja y los ideales con la línea azul, cuyos valores son de 53 y 67, respectivamente.

Además, la línea negra indica de forma constante el alcance total del Sprint. En este caso, 200 PBIs.

Por último, destacar que aunque las gráficas representen el progreso del Sprint de forma distinta, si en la gráfica burn-up se siguiera con una tendencia lineal respecto al día 5 del Sprint, la cantidad de PBIs “hechos” sería igual a los valores ya indicados en la gráfica burn-down, 147 y 133.

Para ello, se ha añadido una nueva línea naranja a modo de estimación del progreso actual.

Misma información, pero dos formas de representación

Es cierto que en el escenario anterior se ha representado la misma información desde diferentes puntos de vista: esfuerzo restante contra el progreso acumulado ya “hecho”.

Si extendemos dicho escenario, podremos ver una ventaja de la gráfica burn-up frente a la de burn-down: el desarrollo continúa hasta el día 6, el equipo ha “hecho” 40 PBIs y el alcance varía en otros 40 PBIs.

Como se aprecia en la gráfica burn-down actualizada, da la sensación de que el equipo no ha realizado ningún avance, ya que los PBIs al final de los días 5 y 6 tienen el mismo valor: 147.

Sin embargo, el equipo ha tenido un muy buen día y ha “quemado” más PBIs que en el resto de Sprint. La gráfica burn-down, por tanto, no refleja correctamente esta situación.

Por el contrario, si este mismo escenario se representa con la gráfica burn-up, se aprecia que durante el día 6 el equipo de Scrum fue capaz de superar el progreso ideal de 80 PBIs, llegando a 96 PBIs “hechos”. El cambio de alcance también se ve reflejado pero sin afectar a la línea roja, sino a la línea negra.

Profundizando en los cambios de alcance

Como hemos visto, los cambios de alcance no le sientan muy bien a las gráficas burn-down. El escenario anterior es un claro ejemplo de ello aunque existen más.

¿Y si el equipo de desarrollo no “quema” ningún PBI durante el día 7 del Sprint pero el alcance aumenta en 5 PBIs?

En esta ocasión la gráfica burn-down ha subido hacia arriba, como si el progreso del equipo de desarrollo fuera negativo. De nuevo es la gráfica burn-up la que es capaz de reflejar correctamente esta situación.

Desafortunadamente, existe un escenario peor, podría bajar el progreso actual y que la gráfica burn-down fuera más difícil de interpretar: ¿qué ha ocurrido? ¿simplemente se han “quemado” varios PBIs, el alcance ha disminuido o aumentado? ¿o bien un trabajo “hecho” no lo estaba como tal?

Burn-up chart y el plan de versiones

Hasta ahora, sólo he usado el eje vertical de las gráficas de quemado para representar la predicción de PBIs en un Sprint. ¿Y si tenemos en cuenta la estimación de los PBIs para lanzar cada una de las versiones de un plan de versiones?

Esta nueva medida nos permite gestionar nuestras expectativas y las de nuestro cliente con algo más de antelación. Lógicamente, e igual que antes, hay que saber que es una predicción teniendo en cuenta que la velocidad del equipo de desarrollo es constante, un progreso ideal.

Otra variable importante son los futuros PBIs. Es muy normal que muchos de ellos estén muy poco definidos, incluso llegando a ni tan siquiera estar creados en muchos otros casos.

Por último, un plan de versiones también realiza una estimación a alto nivel y gracias a la experiencia, predecir cuántos Sprints serán necesarios para abordar cada versión.

Si ponemos todo en la coctelera, se puede emplear la gráfica burn-up y obtener algo parecido al siguiente ejemplo:

Hazme un resumen

Ya tenéis todo lo que sé sobre estas dos gráficas de quemado. Os animo a que las uséis en vuestros proyectos y equipos Scrum y saquéis vuestras propias conclusiones. Por si acaso, yo os dejo una tabla resumen de las mismas:

¡Espero que os resulte de utilidad!