Burndown Chart vs Burnup Chart

Una gráfica de burndown (burndown chart) es una representación visual que muestra la cantidad de trabajo restante a lo largo del tiempo, utilizada habitualmente en marcos de trabajo ágiles como Scrum para monitorizar el progreso de un Sprint o de un proyecto completo. El gráfico permite al equipo y a los stakeholders evaluar rápidamente si el trabajo se está completando al ritmo necesario para cumplir con los plazos establecidos.

El burndown chart es una de las métricas de seguimiento más fundamentales en el desarrollo ágil de software. Su simplicidad visual lo convierte en una herramienta poderosa para la comunicación del estado del proyecto, funcionando como un irradiador de información que cualquier persona puede interpretar de un vistazo.

Ejes

• Eje horizontal (X): representa el tiempo, generalmente en días del Sprint o iteración.
• Eje vertical (Y): representa la cantidad de trabajo restante, medida en story points, horas ideales, número de tareas u otra unidad de estimación elegida por el equipo.

Líneas principales

• Línea de tendencia ideal: una línea recta diagonal que va desde el total de trabajo planificado (esquina superior izquierda) hasta cero (esquina inferior derecha al final del Sprint). Representa el ritmo constante necesario para completar todo el trabajo.
• Línea de trabajo real: muestra el trabajo restante real actualizado diariamente. Su forma revela el patrón de progreso del equipo.

Sprint Burndown

El más común. Muestra el trabajo restante dentro de un Sprint individual (típicamente 1-4 semanas). Se actualiza diariamente durante el Daily Scrum y permite al equipo evaluar si completará todo el Sprint Backlog.

Release Burndown

Muestra el trabajo restante para completar un Release o versión completa del producto. Abarca múltiples Sprints y permite a los stakeholders visualizar el progreso hacia un hito mayor. El eje X muestra los Sprints en lugar de los días.

Epic Burndown

Rastrea el progreso de un Epic (una gran historia de usuario que abarca múltiples Sprints). Es útil para funcionalidades complejas que se descomponen en múltiples historias de usuario.

Los patrones que muestra la línea de trabajo real revelan información valiosa sobre el equipo:

La línea sigue la tendencia ideal

El equipo avanza al ritmo esperado. El trabajo se completará según lo planificado. Es la situación óptima.

La línea está por encima de la tendencia ideal

El equipo va más lento de lo esperado. Puede haber impedimentos, las estimaciones fueron optimistas o el alcance del Sprint es demasiado grande. Es necesario actuar: eliminar impedimentos, renegociar el alcance o buscar ayuda.

La línea está por debajo de la tendencia ideal

El equipo va más rápido de lo esperado. Las estimaciones fueron conservadoras o el equipo es más productivo de lo previsto. El equipo puede considerar incorporar trabajo adicional del Product Backlog.

La línea sube en lugar de bajar

Se está añadiendo trabajo al Sprint (scope creep). Se han descubierto tareas no previstas o se han añadido nuevos requisitos. Es una señal de alarma que debe abordarse.

La línea baja en escalones

El equipo completa trabajo en lotes (por ejemplo, todas las tareas se completan al final del Sprint en lugar de progresivamente). Puede indicar que las historias de usuario son demasiado grandes o que hay un cuello de botella en el proceso de validación.

La línea baja de golpe al final

Todo el trabajo se marca como completado en los últimos días del Sprint. Puede indicar problemas de seguimiento (el equipo no actualiza el estado regularmente) o que el trabajo real de integración y testing se deja para el final.

Paso 1: Establecer la base

Al inicio del Sprint, sumar todos los story points o unidades de trabajo comprometidas en el Sprint Backlog. Este total es el punto de partida del eje Y.

Paso 2: Calcular la línea ideal

Dividir el total de trabajo entre el número de días del Sprint para obtener el ritmo diario ideal. Trazar una línea recta desde el total hasta cero.

Paso 3: Actualizar diariamente

Cada día (idealmente durante o después del Daily Scrum), actualizar el trabajo restante real. Solo se restan los story points de las historias completadas según la Definition of Done.

Paso 4: Analizar tendencias

Comparar la línea real con la ideal para identificar desviaciones y tomar decisiones informadas.

• Actualizar diariamente: la información desactualizada pierde su valor como herramienta de gestión.
• Usar story points, no horas: los story points ofrecen una visión más estable que las horas, ya que no se ven afectados por la variabilidad individual.
• Hacerlo visible: colocar el burndown chart en un lugar donde todo el equipo pueda verlo (irradiador de información).
• No manipular el gráfico: el burndown debe reflejar la realidad, no lo que se desea comunicar.
• Analizar patrones recurrentes: los patrones repetidos en múltiples Sprints revelan problemas sistémicos que deben abordarse en las retrospectivas.

El burnup chart es una alternativa al burndown que muestra el trabajo completado (en lugar del trabajo restante) a lo largo del tiempo:

El burnup chart añade una segunda línea que muestra el alcance total del proyecto. Cuando esta línea sube, indica que se ha añadido trabajo al alcance. Esto hace que el burnup sea superior para detectar y comunicar cambios de alcance.

La mayoría de las herramientas de gestión ágil generan burndown charts automáticamente:

• Jira: burndown charts nativos para Scrum boards, con análisis de Sprint detallado.
• Azure DevOps: gráficos de burndown configurables para Sprints y releases.
• Trello: con power-ups como Agile Tools o Burndown for Trello.
• Asana: con integraciones y reporting.
• Rally (Broadcom): burndown y burnup charts avanzados para SAFe.
• Hojas de cálculo: para equipos que prefieren control total sobre los datos.

¿El burndown chart es obligatorio en Scrum?

No. La Scrum Guide no prescribe el uso de burndown charts. Sin embargo, es una de las prácticas complementarias más comunes porque facilita la transparencia y la inspección, dos pilares de Scrum. Muchos equipos lo encuentran invaluable para el seguimiento del Sprint.

¿Qué hago si el burndown muestra que no completaremos el Sprint?

Comunicar la situación al Product Owner lo antes posible. Juntos, pueden decidir reducir el alcance del Sprint (devolver historias al Product Backlog), eliminar impedimentos que estén ralentizando al equipo, o buscar ayuda externa. La transparencia temprana es preferible a una sorpresa al final del Sprint.

¿Se debe actualizar el burndown cuando se mueven story points o solo cuando se completan historias?

Lo más común es actualizar solo cuando se completan historias (según la Definition of Done). Mover story points parciales genera una ilusión de progreso que puede ser engañosa. El burndown es más fiable cuando refleja trabajo realmente terminado.

¿El burndown chart funciona fuera de Scrum?

Sí. Aunque es más común en Scrum, cualquier equipo que trabaje con un conjunto definido de trabajo en un periodo de tiempo limitado puede beneficiarse de un burndown chart. Sin embargo, los equipos Kanban suelen preferir métricas de flujo como el Lead Time, Cycle Time y el diagrama de flujo acumulativo (CFD).

¿Es mejor un burndown de story points o de tareas?

Ambos enfoques tienen ventajas. El burndown de story points refleja mejor la complejidad del trabajo restante, mientras que el de tareas es más granular y puede mostrar progreso diario con mayor precisión. Lo importante es elegir una métrica y ser consistente. Algunos equipos usan ambos gráficos para obtener perspectivas complementarias.

¿Cómo se gestiona el trabajo no planificado en el burndown?

El trabajo no planificado que se añade durante el sprint (bugs urgentes, cambios de alcance) debería reflejarse en el burndown como un aumento del trabajo restante. Esto proporciona transparencia sobre la verdadera situación del sprint. Si el trabajo no planificado es frecuente, es un tema que debería abordarse en la retrospectiva para encontrar formas de proteger el sprint.

¿Puede el burndown chart reemplazar la daily standup?

No. El burndown chart es una herramienta de visualización, no un sustituto de la comunicación del equipo. La daily standup proporciona contexto cualitativo que el burndown no puede capturar: por qué una tarea está bloqueada, qué ayuda necesita un miembro del equipo, o qué riesgos se han identificado. El burndown chart es un complemento visual de la conversación, no un reemplazo.

¿Cómo evitar que el burndown se convierta en una herramienta de presión?

El burndown chart debe ser propiedad del equipo, no de la dirección. Utilizarlo para presionar o culpar al equipo destruye la confianza y la seguridad psicológica. Para evitar esto, enmarcar siempre el burndown como una herramienta de transparencia y aprendizaje: "¿Qué nos dice este gráfico sobre nuestro proceso?" en lugar de "¿Por qué no estáis en la línea ideal?"

Una gráfica de burnup es una representación visual que muestra la cantidad de trabajo completado a lo largo del tiempo, ilustrando el progreso acumulativo hacia el alcance o los objetivos del proyecto.

El eje x representa el tiempo, típicamente en sprints o semanas, mientras que el eje y representa la cantidad de trabajo completado, a menudo en puntos de historia u otras métricas relevantes.

Es utilizada por los equipos para rastrear y prever el progreso, gestionar cambios de alcance y tomar decisiones basadas en datos.

A diferencia de la gráfica de burnup, la gráfica de burndown rastrea el trabajo restante en lugar del trabajo completado, con la línea de alcance ideal disminuyendo con el tiempo.

La gráfica de burnup es una herramienta comúnmente utilizada en marcos de trabajo ágiles como Scrum para monitorear y gestionar la entrega.

Se dibuja una línea recta para representar el alcance ideal, indicando el trabajo total que necesita ser completado.

La gráfica se actualiza para reflejar cualquier cambio en el alcance, ajustando la línea de alcance ideal en consecuencia.