Scrum es un marco de trabajo ágil que promueve el trabajo colaborativo entre equipos y se caracteriza por la realización de entregas parciales de un producto final de forma regular. Dentro de él, aparecen herramientas como el Burndown Chart, que son de gran ayuda para visualizar y analizar el avance del equipo y conocer si podrá completar el trabajo comprometido a tiempo. En este artículo vamos a ver qué es un Burndown Chart, qué tipos existen, cómo hacer uno y algunos ejemplos.
Seguro que conoces la famosa frase de «lo que no se mide, no se puede mejorar». Pues bien, sin entrar en debates o polémicas de si es verdad o no, está claro que la medición de procesos nos ayuda, como mínimo, a tener una referencia de dónde estamos. Y, con ello, ya podemos trabajar dónde queremos llegar y, en el caso que nos compete hoy, el progreso sobre una cantidad de trabajo determinada: gráfica de Burndown.
Qué vas as ver en esta entrada
¿Qué es un Burndown Chart?
Un Burndown Chart, diagrama de quemado o gráfica de trabajo pendiente es una gráfica en la que podemos ver el estado del progreso de un Sprint. Es una herramienta utilizada en desarrollo ágil de software, sobre todo en Scrum, que relaciona el trabajo pendiente con un periodo de tiempo determinado.
Una gráfica de burndown puede ofrecernos mucha más información que el avance de un Sprint si sabemos interpretarla correctamente y podremos ayudar mucho más a los equipos gracias a esto. Puede aportar tanto valor que merece la pena dedicarle un post entero.
Tipos de gráficas burndown
Hemos dicho que un burndown te informa del estado de un Sprint. ¿Sólo de un Sprint? Aunque aplicarlo a Sprints es lo que está más extendido, se puede aplicar a muchas mas situaciones. Vamos a ver los tres casos de uso principales de una gráfica burndown:
Sprint burndown chart
El caso más habitual es aplicar la gráfica burndown para conocer el estado de progreso del trabajo durante un Sprint.
Release burndown chart
Otro caso de uso sería crear un burndown sobre una entrega, una release. Vamos a imaginar que queremos entregar las funcionalidades A, B y C en un tiempo X en la misma release por motivos de negocio. Una gráfica de burndown alimentada con estos datos también nos ayudará a saber el estado de la entrega independientemente de los Sprints que lo conformen.
Product burndown chart
Otro caso que podríamos aplicarlo sería a un proyecto cerrado. Un proyecto cuyo alcance, tiempo y coste está predefinido. Un burndown alimentado con esta información también podrá ayudarnos a saber si llegamos en fecha y adelantarnos a muchas situaciones como las que veremos a continuación.
¿Cómo se construye un Burndown Chart?
Para montar una gráfica de burndown necesitamos diferentes fuentes de información. Las desgloso por cada eje:
1. Eje X: Tiempo
En el eje X de nuestro burndown representamos el tiempo. Pero un tiempo finito. En el caso de un Sprint, cuando x=0 debe ser el inicio del Sprint y el último valor de nuestro eje X, llamémoslo «t», debe ser el final del Sprint. Si fuese un proyecto cerrado, la fecha de compromiso con el cliente. Si es la entrega de una release, la fecha prevista de despliegue de esa release. Como siempre, esto es muy subjetivo, lo importante es tener un inicio y un final.
2. Eje Y: Cantidad de trabajo
En el eje Y de la gráfica reflejamos la cantidad de trabajo. Es el trabajo que hay comprometido para realizar en el tiempo estipulado. En el caso de Scrum, sería el Sprint Backlog. ¡Ojo! Esto es importante. Para poder montar la gráfica es necesario que las tareas estén estimadas (da igual que sean puntos de historia, jornadas, horas, etc). De esta forma podremos pintar nuestra línea guía.
3. Línea guía: Referencia
Llamamos línea guía a la diagonal que une el último valor de nuestro eje Y (el máximo de trabajo comprometido) con el último valor del eje X (fecha máxima para el trabajo comprometido). Esta será nuestra referencia para saber si vamos bien, vamos mejor que bien o, sin embargo, no va todo tan bien. A continuación, podéis ver una gráfica de burndown vacía, con lo que hemos contado:
4. Línea de progreso
¿Y ya está? No, ahora empieza lo bueno. Empieza el trabajo. Arrancaremos una nueva línea que irá actualizándose con cada tarea (que, recordemos, debe estar estimada) que se termine. Aquí un pequeño paréntesis para recordar la importancia del «Definition of Done». ¿Qué se considera terminado? ¿Estamos todos de acuerdo en cuándo algo se considera terminado y cuándo no? Esa es otra línea de trabajo importante.
Volviendo a nuestra gráfica, por cada tarea terminada, bajaremos la cantidad proporcional a la estimación de la tarea terminada, y, en una situación ideal, tendremos una tendremos una gráfica burndown como la siguiente. En esta gráfica podemos ver como se ha ido entregando tareas, más o menos en línea con nuestra línea de referencia, cumpliendo así con nuestro compromiso:
Ejemplos de Burndown Chart
Pero en un Sprint, en un proyecto, en el día a día… pasan cosas. Vienen impedimentos, dependencias no previstas, etc., que hacen que la gráfica anterior no sea siempre así. Vamos a estudiar dos casuísticas de gráficas burndown que nos pueden ayudar a poner el foco para mejorar el proceso:
Entregas más lentas
En esta gráfica podemos ver, en un vistazo rápido, cómo estamos entregando más «lento» de lo previsto. La línea de progreso, aunque va bajando porque vamos cerrando tareas, no tiene la misma pendiente que la línea de referencia. La consecuencia final de esto es que, si llegamos al final del tiempo, hay una diferencia en el eje X (trabajo) que no ha sido entregado. Es decir, queda trabajo pendiente.
Esto puede poner en peligro fechas de entrega o de releases comprometidas. ¿Qué ventaja tenemos? Al ser una gráfica que podemos ir analizando diariamente, a la mitad del periodo (¡o incluso antes!) ya deberían saltarnos las alarmas de que algo no está yendo como debiera.
Entregas más rápidas
Esta situación es totalmente contraria a la anterior. Nuestra línea de progreso va siempre por debajo de la línea de referencia, llegando al punto de que incluso terminamos con todo el trabajo comprometido antes del tiempo que teníamos. Bendito problema, ¿no? Por supuesto, mejor esta situación que la anterior.
Pero en cualquier caso, nos sirve para indicarnos que hay algo en el proceso poco optimizado. ¿Se está estimando correctamente? ¿La cantidad de trabajo comprometida es correcta?
Conclusión
Una gráfica burndown es una herramienta muy interesante para conocer el avance del trabajo de un equipo durante un Sprint en Scrum. En este post hemos visto en qué consiste, cómo hacer una y hemos analizado dos ejemplos con situaciones diversas. Se pueden dar muchas más (que analizaremos en posteriores posts). Pero, al final, el objetivo es conseguir mejorar de forma continua y esta gráfica nos dará indicaciones para ello.
Aprende más sobre Scrum en nuestro canal de YouTube. ¡Suscríbete!