Burndown chart: qué es y cómo leerlo (sin jerga)

El burndown nació en Scrum como la gráfica mínima de un sprint: en el eje vertical va la cantidad de trabajo restante (puntos, horas o número de tareas), en el eje horizontal los días del sprint. Cada vez que el equipo termina algo, la línea baja. Al final del sprint debería tocar cero.

Tiene dos líneas: la ideal, recta, que asume quemado constante desde el total inicial hasta cero; y la real, que se dibuja con lo que el equipo termina cada día. Toda la lectura está en comparar las dos: la distancia vertical entre ellas es el trabajo que, al ritmo actual, no llegará.

Su gracia es que reemplaza la pregunta “¿cómo van?” —que todos responden con un optimismo educado— por un dato que se actualiza solo: cuánto queda y a qué ritmo baja. Es uno de los pocos KPIs que cumplen la prueba de decisión: si la línea real se separa de la ideal, hoy toca recortar alcance del sprint, no el viernes.

El patrón más común y más peligroso es el escalón final: línea plana toda la semana y caída el último día, cuando “se terminó todo”. Eso no es velocidad, es inventario: tareas que estaban 90% y se cerraron en lote. Si tu burndown siempre es un acantilado, las tareas son demasiado grandes o el equipo solo reporta al final.

El burndown solo dibuja lo que falta. Su primo, el burnup chart, dibuja dos líneas: trabajo terminado (que sube) y alcance total (que también puede subir si entra alcance). La diferencia importa cuando el alcance cambia durante el sprint: en un burndown clásico, un ítem añadido hace subir la línea real y parece “burn-up” confuso; en el burnup, la línea de alcance sube y queda explícito que el compromiso creció.

Regla práctica: burndown para sprints estables donde el alcance no se toca; burnup cuando el alcance cambia (proyectos con cliente, soporte mezclado con desarrollo) o para graficar proyectos completos, donde el alcance casi nunca es fijo.

• Mezclar unidades. Empezar el sprint midiendo puntos y terminar midiendo horas (o al revés) rompe la escala. Elige una unidad y no la cambies a mitad de sprint.
• Actualizar al final. Si las tareas solo se cierran el viernes, el gráfico no anticipa nada: es una foto de la autopsia. Actualizar el tablero al cerrar cada tarea es lo que hace útil al burndown.
• Tratarlo como nota de examen. El burndown no evalúa al equipo, anuncia el futuro del sprint. Usarlo para señalar culpables garantiza que la gente deje de mover el tablero con honestidad, y entonces la gráfica sí se rompe: miente.

Y una limitación que conviene aceptar: el burndown dice cuánto falta, no qué falta. Si el ítem más riesgoso es el último de la fila, la línea puede verse cómoda y el sprint seguir en peligro. Por eso conviene leerlo junto al ordenamiento que sale del sprint planning: los riesgos primero.

Un burndown cabe en una hoja de cálculo: columna de días del sprint, columna de trabajo restante (total del sprint menos lo terminado acumulado cada día) y una gráfica de líneas con la serie ideal al lado. Cinco minutos de armado, treinta segundos de actualización diaria.

Para el seguimiento semanal del proyecto completo (más allá del sprint), el burndown se combina con los demás indicadores del tablero de KPIs del proyecto: la línea dice si el sprint cierra; la fecha proyectada de fin y el presupuesto dicen si el proyecto llega.