Burndown Chart: Qué Es y Cómo Leerlo

Un Burndown chart es la señal más útil que un equipo Scrum puede revisar cada mañana. De un vistazo, muestra si el Sprint está en camino, si se está atrasando o si silenciosamente está acumulando alcance que nadie planificó.
Datos clave
- Los Burndown charts se originaron con el artículo de Ken Schwaber de 2000 sobre gestión de procesos Scrum y han seguido siendo el artefacto Scrum más utilizado desde entonces (Scrum Alliance, 2023).
- Los equipos que actualizan sus Burndown charts diariamente reportan un 17% mejor cumplimiento del objetivo del Sprint que los equipos que actualizan semanalmente (State of Agile Report 17th edition, 2024).
- La línea de Burndown "ideal" asume un progreso diario uniforme, pero los Sprints reales muestran una curva en J con entrega concentrada al final en aproximadamente el 60% de los casos (encuesta de la comunidad Atlassian, 2023).
¿Qué es un Burndown chart?
Un Burndown chart es un gráfico que rastrea cuánto trabajo queda en un Sprint o proyecto a lo largo del tiempo, con el objetivo de llegar a cero para la fecha límite. El eje horizontal representa el tiempo (días, Sprints o semanas), y el eje vertical representa el trabajo restante (Story Points, horas o tareas). A medida que el equipo completa trabajo, la línea "se quema" hacia cero.
Los Burndown charts pertenecen al conjunto de herramientas de Scrum, aunque los equipos que usan otras metodologías Agile también los adoptan. El atractivo principal es la simplicidad: no necesita interpretar docenas de métricas para entender el progreso del equipo. Dos líneas cuentan toda la historia.
El gráfico es distinto de un diagrama de Gantt, que mapea tareas a fechas, o de un diagrama PERT, que se centra en las dependencias de las tareas. Un Burndown chart no se preocupa por las tareas individuales. Solo hace una pregunta: ¿cuánto trabajo queda y ese número está disminuyendo lo suficientemente rápido?
Cómo funciona un Burndown chart (las dos líneas)
Cada Burndown chart tiene dos líneas:
La línea ideal (también llamada línea de referencia o línea guía) corre como una diagonal recta desde la esquina superior izquierda hasta la esquina inferior derecha. Comienza en el compromiso total del Sprint (por ejemplo, 80 Story Points el Día 0) y termina en cero el último día. Esta línea asume que el equipo trabaja a un ritmo perfectamente uniforme cada día. Nadie espera que esto suceda realmente. La línea ideal existe como punto de referencia, no como predicción.
La línea real representa el trabajo restante real tal como se registra cada día. Se actualiza en el Standup diario o al final de cada jornada laboral. Cuando esta línea está por encima de la línea ideal, el equipo está atrasado. Cuando está por debajo, el equipo va adelantado. Cuando se aplana (sin movimiento hacia abajo), el trabajo no se está completando o no se está registrando. Cuando sube repentinamente, se ha añadido nuevo alcance al Sprint.
Los ejes:
- Eje X: Días del Sprint, numerados del 0 (o 1) al día final
- Eje Y: Trabajo restante, medido en Story Points u horas
El valor inicial en el eje Y equivale al compromiso total del Sprint. Cero en el eje Y significa que el Sprint está completo.
Sprint Burndown vs Release Burndown
Los equipos usan dos variantes principales. Responden preguntas diferentes y sirven a audiencias distintas.
| Sprint Burndown | Release Burndown | |
|---|---|---|
| Alcance | Un Sprint (1-4 semanas) | Múltiples Sprints hacia un lanzamiento |
| Unidad del eje Y | Story Points u horas | Historias, funcionalidades o épicas |
| Unidad del eje X | Días dentro del Sprint | Sprints restantes |
| Audiencia principal | Equipo de desarrollo + Scrum Master | Product Owner + stakeholders |
| Frecuencia de actualización | Diaria | Al final de cada Sprint |
| Pregunta clave | ¿Terminaremos este Sprint? | ¿Alcanzaremos la fecha de lanzamiento? |
| Señal de alerta | Línea plana, pico hacia arriba | Tasa de Burndown lenta frente al crecimiento del Backlog |
La mayoría de los equipos comienzan con Sprint Burndowns. Los Release Burndowns se vuelven valiosos una vez que un equipo tiene suficiente historial de Sprints para proyectar una Velocity confiable. Ambos se complementan con herramientas como la estructura de desglose del trabajo y los documentos de planificación del ciclo de vida del proyecto.
Cómo leer un Burndown chart (4 patrones comunes)

Aprender a leer un Burndown chart significa reconocer cuatro formas recurrentes. Cada una cuenta una historia diferente sobre la salud del Sprint.
Patrón 1: Siguiendo la línea ideal
La línea real se mantiene cerca de la línea ideal, desviándose ligeramente por encima o por debajo, pero nunca alejándose demasiado. Esto es lo que parece una ejecución de Sprint saludable. No significa que todo sea perfecto. Significa que los impedimentos se están resolviendo rápidamente y que el equipo estimó razonablemente.
Patrón 2: Por debajo del cronograma
La línea real corre constantemente por encima de la línea ideal. La brecha entre las dos líneas crece a medida que pasan los días. Para el Día 5 de un Sprint de 10 días, el equipo puede haber completado solo el 20% del trabajo cuando se esperaba el 50%. Este patrón requiere una conversación inmediata en el Standup diario. Causas comunes: las historias fueron subestimadas, los miembros del equipo están bloqueados o el Sprint tenía un sobrecompromiso desde el inicio.
Patrón 3: Por delante del cronograma
La línea real cae por debajo de la línea ideal y se mantiene allí. El equipo está avanzando más rápido de lo planificado. Esto suena bien, pero vale la pena preguntarse por qué. O bien las historias fueron sobreestimadas (lo que infla las métricas de Velocity), o el equipo está recortando en calidad. Si la estimación fue simplemente conservadora, el equipo puede incorporar historias del Backlog para mantener el impulso.
Patrón 4: Expansión del alcance
La línea real sube repentinamente a mitad del Sprint en lugar de continuar hacia abajo. Este pico significa que se añadió trabajo nuevo al Sprint después de que comenzara. Un pequeño salto puede ser aceptable para correcciones críticas. Un pico grande o repetido indica una planificación deficiente del Sprint o presión para aceptar solicitudes a mitad del Sprint sin negociación. Compare esto con los principios de Scrum vs Kanban: Kanban permite explícitamente cambios de flujo a mitad del ciclo, mientras que Scrum apunta a la estabilidad del Sprint.
Cómo crear un Burndown chart: paso a paso
Paso 1: Recopile los datos del Sprint
Antes de tocar un gráfico, recopile dos números: total de Story Points (u horas) comprometidos al Sprint, y el número de días laborables en el Sprint. Estos definen su punto de partida y su punto final. Documente ambos en sus notas de planificación del Sprint.
Paso 2: Configure los ejes
Dibuje o configure su gráfico con los días en el eje X (del 0 al día final) y el trabajo restante en el eje Y (de 0 al total comprometido). Etiquete ambos ejes claramente. Si está construyendo en una hoja de cálculo, congele la fila de encabezado y la columna de días para que permanezcan visibles a medida que avanza el Sprint.
Paso 3: Trace la línea ideal
Conecte dos puntos: (Día 0, compromiso total) y (día final, 0). Esta línea recta es su referencia. En una hoja de cálculo, una fórmula SLOPE simple se encarga de esto. En Jira o Azure DevOps, la herramienta la dibuja automáticamente cuando usted establece las fechas del Sprint y los totales de Story Points.
Paso 4: Trace el trabajo real diariamente
Al final de cada jornada laboral (o durante el Standup), registre los Story Points restantes. "Restante" significa la suma de Story Points de todas las historias incompletas. No reste crédito parcial por historias en progreso. Una historia está hecha o no lo está. Esta regla binaria mantiene el gráfico honesto y evita señales de progreso falsas.
Paso 5: Interprete y actúe
No se limite a actualizar el gráfico y seguir adelante. El punto de datos de cada día es un disparador para una conversación. ¿La línea real está por encima de la ideal? ¿Qué está bloqueando al equipo? ¿Una historia está tardando más de lo estimado? ¿Esas historias deben desglosarse más? El Burndown chart es más útil cuando impulsa acciones específicas, no solo reportes.
Ejemplos de Burndown chart por equipo

Los diferentes equipos usan los Burndown charts de formas ligeramente distintas. La mecánica central permanece igual. La duración del Sprint, la escala de Story Points y la cadencia de actualización varían según el tamaño del equipo y el flujo de trabajo.
| Tipo de equipo | Duración del Sprint | Unidad del eje Y | Patrón típico | Problema común |
|---|---|---|---|---|
| Ingeniería (producto) | 2 semanas | Story Points | Entrega concentrada al final | Historias completadas en los últimos 2 días |
| Campaña de marketing | 1 semana | Número de tareas | Plano luego empinado | Las aprobaciones bloquean el progreso hasta el Día 3 |
| Diseño | 2 semanas | Horas | Sigue la línea ideal de cerca | Expansión del alcance por rondas tardías de retroalimentación |
| Soporte / operaciones | 1 semana | Número de tickets | A menudo por delante de la ideal | Los tickets se resuelven más rápido de lo estimado |
Los equipos de ingeniería ven con más frecuencia el patrón de curva en J: quema lenta en la primera mitad, luego finalización rápida en la segunda mitad cuando el trabajo de integración y revisión converge. Los equipos de marketing tienden a ver líneas planas a mitad del Sprint porque el trabajo se acumula esperando aprobación. Los equipos de diseño siguen más de cerca la línea ideal cuando se respetan las ceremonias del Sprint, pero sufren más de la expansión del alcance cuando las revisiones de los stakeholders llegan tarde.
Burndown vs Burnup chart
Los gráficos Burndown y Burnup son parientes cercanos, pero responden preguntas ligeramente diferentes.
Un Burndown chart rastrea el trabajo restante. La línea va de alto a cero. El enfoque está en lo que queda.
Un Burnup chart rastrea el trabajo completado. La línea va de cero hacia arriba. Una segunda línea muestra el alcance total. La brecha entre las dos muestra cuánto trabajo queda.
La ventaja clave del Burnup chart es la transparencia sobre los cambios de alcance. Cuando se añaden nuevas historias, la línea de alcance total sube, y todos pueden ver tanto el trabajo añadido como el progreso en el compromiso original. En un Burndown chart, las adiciones de alcance aparecen como picos hacia arriba, que pueden ser más difíciles de interpretar de un vistazo.
La mayoría de los equipos Scrum comienzan con Burndown charts porque son más simples. Los equipos con cambios frecuentes de alcance a menudo cambian a Burnup charts porque separan la pregunta "¿cuánto hicimos?" de la pregunta "¿cuánto nos añadieron?" Algunos equipos muestran ambos lado a lado durante las revisiones del Sprint.
Errores comunes (y cómo corregirlos)
| Error | Corrección |
|---|---|
| Contar historias en progreso como parcialmente completadas | Use hecho/no hecho de forma binaria. Sin crédito parcial. |
| Actualizar una vez por semana en lugar de diariamente | Actualice en el Standup cada día. Los datos obsoletos ocultan problemas. |
| Reiniciar el gráfico después de añadir alcance en lugar de mostrar el pico | Deje que el pico se muestre. Es información, no motivo de vergüenza. |
| Culpar al equipo por la forma del gráfico | Use el gráfico para encontrar causas sistémicas, no para asignar culpas. |
| Tratar una línea por debajo de la ideal como puramente buenas noticias | Pregúntese si las historias fueron sobreestimadas o si se recortó en calidad. |
| Omitir el gráfico cuando el Sprint va mal | Los Sprints malos son exactamente cuando el gráfico más importa. |
| Mezclar diferentes tipos de unidades (horas para algunas historias, puntos para otras) | Elija una unidad y manténgala durante todo el Sprint. |
Mejores prácticas
- Actualice el gráfico a la misma hora todos los días. Los Standups matutinos funcionan bien porque el equipo discute los bloqueos justo después de actualizar. La consistencia importa más que el momento exacto.
- Mantenga visible la línea ideal en todo momento. No la oculte cuando la línea real diverge. La divergencia es el punto.
- Muestre el gráfico donde el equipo pueda verlo. Un Dashboard compartido o una pantalla en el espacio de trabajo físico del equipo mantiene el estado del Sprint en primer plano sin requerir esfuerzo adicional para consultarlo.
- No añada historias a un Sprint sin ajustar el compromiso total. Si entra nuevo trabajo al Sprint, el punto de inicio del eje Y debe reflejar el nuevo total. De lo contrario, el gráfico subestima el trabajo restante.
- Use el gráfico en las retrospectivas, no solo en los Standups. La forma del Burndown final es un valioso disparador para la retrospectiva. Un patrón persistente de plano-luego-empinado puede indicar que las ceremonias del Sprint necesitan mejorar o que las historias son demasiado grandes.
- Complémentelo con un gráfico de Velocity a lo largo del tiempo. El Burndown de un único Sprint muestra la salud actual. La Velocity a lo largo de 5-6 Sprints revela si el equipo está mejorando, estabilizándose o declinando.
- Mantenga la granularidad de las historias consistente. Las historias de más de 8 Story Points rara vez se queman fluidamente. Desgloselas. Las historias grandes crean una falsa planitud en el gráfico hasta que repentinamente están "hechas" de una sola vez.
- No use el Burndown chart para evaluar el rendimiento individual. Refleja el progreso a nivel de equipo. Usarlo para detectar personas que "no están contribuyendo" malinterpreta los datos y daña la confianza.
Preguntas frecuentes
¿Qué significa una línea plana en un Burndown chart?
Una línea plana significa que no se completó trabajo durante ese período, al menos según lo que se registró. Las causas más comunes son: las historias no se están cerrando en el sistema de seguimiento aunque el trabajo esté hecho, el equipo está bloqueado por una dependencia o falta una entrada, o el trabajo está detenido en revisión y no ha superado la Definition of Done. Revise el sistema de seguimiento primero antes de asumir que el equipo dejó de trabajar.
¿Qué es la línea de Burndown ideal?
La línea ideal es una diagonal recta que va desde el compromiso total del Sprint el Día 0 hasta cero el último día. Representa un progreso diario perfectamente uniforme. Ningún Sprint real se parece a esto, y está bien. Existe como punto de referencia para que el equipo pueda ver cuánto se desvía el progreso real de una base de referencia teórica.
¿Cuál es la diferencia entre Burndown y Velocity?
Un Burndown chart muestra el trabajo restante dentro de un único Sprint. La Velocity mide cuántos Story Points completó un equipo a lo largo de múltiples Sprints, generalmente promediados durante los últimos tres a cinco. Burndown es una señal dentro del Sprint. La Velocity es una tendencia entre Sprints. Ambas importan para la planificación del Sprint: la Velocity le indica cuánto comprometerse, el Burndown le indica si está cumpliendo con ese compromiso.
¿Debo usar Story Points u horas?
Cualquiera funciona. Los Story Points son más comunes en los equipos de ingeniería de producto porque abstraen las diferencias de habilidades individuales y se centran en la complejidad relativa. Las horas funcionan bien para equipos con tipos de tareas altamente predecibles, como soporte o diseño. La regla más importante es la consistencia: elija una unidad para su equipo y no cambie a mitad del proyecto, o sus gráficos serán imposibles de comparar con el tiempo.
¿Con qué frecuencia debo actualizar un Burndown chart?
Diariamente es el estándar. Actualizar en el Standup diario o al final del día mantiene el gráfico lo suficientemente preciso como para detectar problemas temprano. Las actualizaciones semanales dejan una semana de riesgo invisible. Algunos equipos actualizan dos veces al día durante Sprints de alto riesgo, aunque lo diario es suficiente para la mayoría de las situaciones.
Los Burndown charts funcionan porque identifican la realidad rápidamente. Un equipo que mira su Burndown cada mañana no puede ocultarse de un Sprint malo por mucho tiempo, y esa visibilidad es exactamente lo que lo hace útil. Ya sea que esté usando Scrum, experimentando con Kanban o gestionando un proyecto de método mixto a través del método de la ruta crítica, el Burndown chart le brinda una vista limpia y honesta del progreso. Comience a hacer seguimiento hoy, y descubrirá que se convierte en una de las primeras cosas que el equipo revisa cada mañana.

Senior Operations & Growth Strategist
On this page
- ¿Qué es un Burndown chart?
- Cómo funciona un Burndown chart (las dos líneas)
- Sprint Burndown vs Release Burndown
- Cómo leer un Burndown chart (4 patrones comunes)
- Patrón 1: Siguiendo la línea ideal
- Patrón 2: Por debajo del cronograma
- Patrón 3: Por delante del cronograma
- Patrón 4: Expansión del alcance
- Cómo crear un Burndown chart: paso a paso
- Paso 1: Recopile los datos del Sprint
- Paso 2: Configure los ejes
- Paso 3: Trace la línea ideal
- Paso 4: Trace el trabajo real diariamente
- Paso 5: Interprete y actúe
- Ejemplos de Burndown chart por equipo
- Burndown vs Burnup chart
- Errores comunes (y cómo corregirlos)
- Mejores prácticas
- Preguntas frecuentes