Burn-up chart

Tiempo aproximado: 5 min.

El burn-up chart (literalmente “gráfico de quemado hacia arriba”) muestra el trabajo aportado por un equipo, o varios, a un proyecto ágil. Aunque resulta poco conocido, es uno de los gráficos más útiles para gestionar el trabajo de un equipo haciendo Scrum porque nos permite tomar decisiones realistas acerca del trabajo pendiente y las expectativas alrededor del mismo.

¿Cómo se hace?

Mostramos en el eje horizontal la duración del proyecto, medido en sprints (todos de la misma duración), y los puntos en los que hemos estimado las historias de nuestro product backlog en el eje vertical.

Vamos trazando, iteración tras iteración, una linea que irá uniendo los puntos entregados. De manera acumulada, puesto que estamos representando la cantidad de software con valor que hemos entregado hasta ese momento. Por tanto, la pendiente de esta gráfica se corresponde con la velocidad a la que estamos consumiendo (“quemando”) el backlog, de ahí el nombre de “burn-up chart”.

Burnupchart-1

El tamaño del backlog se obtiene como una estimación temprana que habrá que actualizar, de ahí que en la imagen a continuación lo veamos como una linea (gris) que también se actualiza.

Burnupchart-3

¿Para qué sirve?

Principalmente usamos el burn-up chart para ayudar al equipo a encontrar su ritmo sostenible. Además, cuando la velocidad de éste se estabiliza (normalmente al cabo de 4-5 iteraciones), podemos hacer un cálculo de cuándo podría acabarse el proyecto.

Observa en la imagen a continuación cómo podemos responder a la pregunta “¿Cuándo estará acabada esta versión del producto?”. Simplemente hay que proyectar la linea de software entregado y calcular dónde se corta con nuestra estimación del product backlog.

Burnupchart-2

¡Ojo! La proyección que hacemos está basada en la velocidad actual del equipo. Pero no podemos predecir el futuro con una certeza del 100%. Por ello deberíamos representar la proyección del gráfico variando en un rango de probabilidades, con lo que la fecha esperada de conclusión también debería ser representada con un margen. Es lo que muestran las lineas naranjas en la imagen anterior.

También es útil para resaltar el hecho de que el proyecto no es predictivo, al no tener un final determinado ni una velocidad ideal a la que el equipo debería ajustarse. Justamente ésta es la diferencia fundamental con el burn-down chart, mucho más conocido.

Actualizando el gráfico al final de cada sprint podremos hacernos una idea sobre cuándo, aproximadamente, podrá estar acabada la versión en curso (o el proyecto entero). Para ello es imprescindible que el equipo mantenga un ritmo sostenible. De lo contrario la estimación no será creíble.

Para que nuestra proyección sea más creíble aún, es muy recomendable:

  • que cada versión de nuestro producto sea lo más sencilla posible,
  • que todos los que participan en su construcción hayan conversado lo suficiente y se sientan cómodos con las estimaciones acordadas, y
  • mantener actualizado el valor estimado del backlog.

Burn-up chart con el plan de versiones

Hasta aquí hemos visto que en el eje vertical del burnup chart representamos la estimación del backlog sólo para la versión que estamos construyendo del producto y no de las que tenemos previstas. Si en su lugar representamos la estimación de cada versión, obtenida de nuestro plan de versiones, obtenemos una gráfica como la de la imagen a continuación. Esta gráfica nos permite gestionar nuestras expectativas y las de nuestros clientes con algo más de antelación. Lógicamente, igual que antes, el ritmo sostenible es fundamental para que la proyección que hagamos sea realista.

Burnupchart-4

Si por alguna razón tienes problemas para conseguir una estimación del backlog, puedes conseguir un efecto similar con una técnica más tradicional. Puedes idealizar la velocidad del equipo (la línea verde) y estimar la duración (en sprints) de cada versión. De esa manera puedes tener una primera “instantánea” de vuestro plan y ayudar así a tomar decisiones de priorización antes de comenzar el desarrollo. Sí, obtienes un diagrama de Gantt. Cuidado con él. 🙂

Burnupchart-6

Fechas límite

Gestionar expectativas es una parte importante del trabajo del Dueño de Producto. En algún momento tendremos que responder a las típicas preguntas de “¿Cómo de grande es esto?”, “¿Cuándo terminará?” o “¿Cuánto nos va a costar?”. Al construir un User Story Map con el que planificar nuestro desarrollo es frecuente enfrentarse a restricciones como fechas límite (p.ej. una campaña de marketing o la entrada en vigor de una ley). Por todo ello es necesario realizar estimaciones.

Recuerda que no es lo mismo “estimar” que “predecir”. La estimación se hace con incertidumbre y podemos reducirla, pero no eliminarla completamente. Para ello:

  • hacemos cosas pequeñas, y
  • buscamos el ritmo sostenible del equipo.

Al contrario del burn-down chart, el burn-up chart nos ofrece una visión de evolución constante del proyecto. Podemos aprovechar esto para hacer entender a nuestro cliente que, si nos acercamos peligrosamente a una fecha límite, la funcionalidad en riesgo será la que menos valor aporte en comparación a lo ya construído y que, además, siempre tendremos software funcionando, con lo que eliminamos el riesgo de llegar a la fecha límite sin nada que entregar. Así, el Dueño de Producto puede reordenar la prioridad del backlog para asegurarse de que no queda ninguna funcionalidad importante fuera del producto a entregar antes de la fecha límite.

Burnupchart-5

En la imagen anterior se observa cómo el Dueño de Producto ha reducido el ámbito del proyecto en la última iteración, por lo que ha disminuido el tamaño estimado del backlog. Ahora, la proyección del burn-up nos permite confiar en que el equipo, si sigue con esa velocidad, llegará a completar el backlog antes de la fecha límite.

Para ampliar:

PUBLICIDAD:

Si estás interesado en recibir formación, puedes leer sobre los servicios que ofrezco o ponerte en contacto conmigo.