Un gráfico de burndown es una representación visual del trabajo pendiente que muestra, a lo largo del tiempo, la cantidad de esfuerzo o unidades de trabajo que restan por completar en un proyecto, iteración o lanzamiento. Este instrumento, ampliamente difundido en la gestión ágil de proyectos, permite a los equipos y a las partes interesadas evaluar de un vistazo si el ritmo de avance es suficiente para alcanzar los objetivos dentro del plazo previsto. El gráfico contrapone una línea ideal —que desciende de manera constante desde el total estimado hasta cero— con la línea real que refleja el trabajo aún remanente tras cada jornada o medición. Aunque su origen está íntimamente ligado a Scrum y a las metodologías de desarrollo de software, su lógica subyacente ha trascendido a entornos híbridos y predictivos donde la transparencia en la ejecución resulta crítica.
El verdadero valor del gráfico de burndown reside en su capacidad para convertir datos abstractos de progreso en una forma visual instantáneamente interpretable. No es simplemente una herramienta de reporting; funciona como un radar de alerta temprana que expone desviaciones antes de que se conviertan en crisis de cronograma. Cuando la línea real se sitúa persistentemente por encima de la ideal, el equipo y el gestor del proyecto deben indagar las causas: sobrestimación de la capacidad, impedimentos técnicos, alcance no controlado o dinámicas de equipo que frenan la productividad. Si la línea real cae por debajo, podría indicar que las estimaciones iniciales fueron demasiado conservadoras o que se ha eliminado trabajo sin registrar el ajuste. En ambos casos, el gráfico no dicta soluciones, pero enfoca la conversación donde realmente hace falta.
Tabla de puntos clave del Gráfico de Burndown
| Concepto clave | Resumen |
|---|---|
| Definición esencial | El gráfico de burndown es una herramienta visual de la gestión ágil que permite determinar con rapidez si el ritmo de avance resulta suficiente para alcanzar los objetivos comprometidos dentro del plazo establecido. |
| Origen y contexto | Surgió a principios de la década de 1990 como parte del marco Scrum, concebido por Ken Schwaber y Jeff Sutherland, con el propósito de transparentar el trabajo restante durante un sprint. |
| Antecedentes históricos | La práctica de monitorizar la reducción progresiva de una variable en el tiempo ya se aplicaba en la manufactura esbelta, la aviación y la logística militar, mucho antes de su adopción en el ámbito del software. |
| Plataformas clave | Jira, Azure DevOps y Trello incorporaron la generación automática de gráficos de burndown, lo que masificó su adopción y eliminó la necesidad de trazarlos manualmente. |
| Estructura del gráfico | El eje vertical representa el trabajo pendiente, medido en horas, puntos de historia o unidades equivalentes, mientras que el eje horizontal refleja la duración del sprint; sobre estos ejes se superponen la línea ideal de quema y la línea real registrada diariamente. |
| Interpretación de desviaciones | Cuando la línea real se mantiene de forma reiterada por encima de la ideal, el equipo debe investigar causas subyacentes como una estimación excesivamente optimista de la capacidad, bloqueos técnicos, expansión descontrolada del alcance o disfunciones en la colaboración del equipo. |
| Ámbitos de aplicación | La lógica subyacente del burndown trasciende el desarrollo de software y aporta valor en contextos híbridos y predictivos donde la visibilidad sobre el avance de la ejecución resulta determinante para la toma de decisiones. |
Origen y evolución del gráfico de burndown
La historia del gráfico de burndown se remonta a los primeros años de Scrum, el marco creado por Ken Schwaber y Jeff Sutherland a principios de la década de 1990. El origen del gráfico de burndown en gestión de proyectos está directamente vinculado con la necesidad de los equipos de software de visualizar cuánto trabajo faltaba para terminar un sprint, algo que los diagramas de Gantt o las listas de tareas no reflejaban con la suficiente inmediatez. Schwaber documentó el uso de lo que llamó “Sprint Burndown Chart” como un artefacto central para la transparencia del progreso durante la reunión diaria. La idea de una línea que “quema” trabajo pendiente ya existía en otros campos, aunque con nombres distintos; en la manufactura esbelta, por ejemplo, los tableros de control visual llevaban décadas mostrando la reducción de inventario de trabajo en curso, un concepto análogo en espíritu.
Fuera del ámbito del software, la noción de seguir la disminución de una magnitud a lo largo del tiempo tiene raíces profundas en disciplinas como la aviación (monitoreo de consumo de combustible) y la gestión militar de suministros. No obstante, la formalización del burndown chart como artefacto de gestión de proyectos se consolidó con la publicación del manifiesto ágil en 2001 y la posterior adopción masiva de Scrum. El término en inglés “burndown” (literalmente “quemar hacia abajo”) se tradujo en el mundo hispanohablante como “gráfico de burndown” o, en menor medida, “diagrama de avance del trabajo restante”. La expresión ha calado con fuerza en el léxico del project management sin necesidad de una adaptación forzada, a diferencia de otros anglicismos.
Con el paso de los años, el gráfico dejó de ser exclusivo del sprint de desarrollo y se extendió a la planificación de releases y a programas completos. Las herramientas digitales como Jira, Azure DevOps o Trello incorporaron generación automática de burndowns, democratizando su uso y eliminando la carga de dibujarlo manualmente. Este salto tecnológico, lejos de trivializar el concepto, lo convirtió en un estándar de facto para cualquier equipo que opere con iteraciones y trabajo incremental, independientemente de su sector.
Puntos clave del origen del burndown
- Origen en Scrum de los 90
- A principios de los años 90, Ken Schwaber y Jeff Sutherland idearon el gráfico de burndown dentro del marco Scrum para ofrecer una visualización diaria y transparente del trabajo restante en el sprint, transformando la forma de seguir el progreso.
- Formalización con el manifiesto ágil
- Tras la firma del Manifiesto Ágil en 2001, la adopción masiva de Scrum convirtió al burndown en un pilar de transparencia para las reuniones diarias, permitiendo a los equipos autoevaluarse y a los stakeholders anticipar desviaciones.
- Estandarización mediante herramientas digitales
- La incorporación de la generación automática de gráficos de burndown en herramientas como Jira y Trello eliminó el esfuerzo manual, estableciéndolo como el referente indiscutible para visualizar el avance en ciclos iterativos.
Componentes fundamentales y variantes del gráfico de burndown
Los elementos del gráfico de burndown se estructuran alrededor de un sistema de coordenadas simple pero potente. El eje horizontal representa el tiempo, generalmente medido en días hábiles de una iteración o en fechas de calendario para un release. El eje vertical muestra la cantidad de trabajo pendiente, que puede expresarse en horas de esfuerzo, puntos de historia, número de tareas o cualquier unidad que el equipo haya acordado como indicador fiable del volumen por completar. Sobre este lienzo se trazan dos líneas: la línea ideal de quema, que desciende en diagonal uniforme desde el valor total del trabajo estimado al inicio hasta cero al final del periodo, y la línea real, que se construye punto a punto cada día al registrar el trabajo restante. La separación entre ambas líneas es el mensaje central del gráfico.
Cuando un equipo emplea puntos de historia, la lectura del burndown exige una capa adicional de interpretación. Los puntos de historia estiman el tamaño relativo del trabajo considerando complejidad, incertidumbre y esfuerzo, por lo que un descenso de diez puntos no equivale necesariamente a una reducción proporcional del riesgo o del valor entregado. Esta característica provoca que muchos profesionales prefieran usar horas ideales de trabajo para mantener una relación más intuitiva con las desviaciones. Sin embargo, las horas ideales también pueden enmascarar realidades si el equipo no comparte un entendimiento homogéneo de lo que constituye una hora de esfuerzo puro, libre de interrupciones.
Línea ideal versus línea real
La línea ideal es una construcción matemática, no una predicción. Asume que el ritmo de finalización del trabajo será perfectamente constante durante toda la ventana temporal, algo que raramente ocurre en entornos reales. Un proyecto con mucha incertidumbre técnica puede mostrar un inicio casi plano, mientras el equipo dedica días a resolver bloqueos, y luego un descenso acelerado cuando las piezas empiezan a encajar. Esa curva con forma de palo de hockey sorprende a los observadores inexpertos, pero es totalmente esperable en contextos de alta exploración. La línea real, en cambio, captura el efecto de los impedimentos, los cambios de prioridad y los picos de productividad que caracterizan la ejecución cotidiana. Cuanto más se aleje la línea real de la ideal, más urgente es la conversación sobre las causas.
Burndown de sprint frente a burndown de release
El burndown de sprint se enfoca en una iteración corta, habitualmente de una a cuatro semanas, y su granularidad es diaria. Muestra cuántas unidades de trabajo quedan dentro de ese sprint específico, asumiendo un alcance congelado o cuasi congelado durante la iteración. El burndown de release extiende la mirada a un horizonte mayor, que puede abarcar varios sprints, y suele utilizar la velocidad media del equipo para proyectar la fecha de finalización del producto o del lanzamiento. Mientras que el primero es un instrumento táctico de inspección diaria, el segundo adquiere una dimensión estratégica para la planificación de roadmap y la gestión de expectativas de los stakeholders.
En la práctica, un burndown de release integra la evolución del backlog del producto, que cambia continuamente porque los stakeholders afinan los requisitos o el mercado impone ajustes. Por ello, la línea de trabajo pendiente en un burndown de release puede subir bruscamente si se añaden nuevas historias de usuario, algo que jamás debería ocurrir en un burndown de sprint salvo que se detecte un error grosero en la planificación inicial. La disciplina de no alterar el alcance durante el sprint es una de las reglas que preservan la utilidad del burndown como espejo del progreso real.
El gráfico de burndown en los marcos de gestión de proyectos
La Guía del PMBOK, en su séptima edición, abandona la estructura de procesos y áreas de conocimiento para abrazar principios y dominios de desempeño. Dentro de ese nuevo enfoque, el gráfico de burndown aparece como un ejemplo de medición de la entrega de valor y del progreso en equipos que operan bajo ciclos de vida adaptativos. El gráfico de burndown en PMBOK se menciona en el dominio de desempeño de la medición, como una de las herramientas visuales que permiten evaluar si el ritmo de trabajo es sostenible y si el equipo está cumpliendo con las metas de la iteración. Anteriormente, en la sexta edición, se aludía a los gráficos de quema pendiente dentro del apéndice sobre prácticas ágiles, pero sin un tratamiento tan integrado.
PRINCE2 Agile, la extensión del método PRINCE2 para entornos ágiles, reconoce el valor del gráfico de burndown como un informe de progreso que complementa los mecanismos formales de control del proyecto. En PRINCE2, el foco está en la justificación continua del negocio y en la gestión por fases, y un burndown chart permite al director de proyecto visualizar si la fase actual o la entrega planificada están dentro de las tolerancias de tiempo y alcance acordadas. La metodología no prescribe un formato único, sino que anima al equipo a seleccionar la representación visual más transparente posible, siendo el burndown una de las opciones más frecuentes cuando se trabaja con timeboxes.
En Scrum, el gráfico de burndown no forma parte del núcleo de artefactos definidos en la Guía de Scrum (los artefactos son el Product Backlog, el Sprint Backlog y el Increment), pero se ha consolidado como una práctica complementaria casi universal. El Scrum Master lo actualiza o lo expone durante la reunión diaria, y el equipo lo utiliza para inspeccionar su progreso hacia el objetivo del sprint. En entornos híbridos donde coexisten fases predictivas con paquetes de trabajo ejecutados de forma iterativa, el burndown convive con estructuras de desglose del trabajo y cronogramas de hitos. Suele emplearse en los entregables que se desarrollan bajo lógica ágil, mientras que los componentes más predecibles se gobiernan con técnicas tradicionales de valor ganado.
Ideas clave sobre el burndown
- PMBOK 7: burndown en la medición del desempeño
- A diferencia de la sexta edición, que solo lo mencionaba en el apéndice de prácticas ágiles, la séptima edición del PMBOK integra el burndown en el dominio de medición del desempeño como una herramienta visual para verificar la sostenibilidad del ritmo de trabajo y el cumplimiento de los objetivos de la iteración.
- PRINCE2 Agile: informe de progreso complementario
- PRINCE2 Agile considera el gráfico de burndown como un informe complementario de progreso que, junto con los mecanismos formales de control, permite al director de proyecto verificar si la fase en curso o la entrega planificada se mantienen dentro de las tolerancias de tiempo y alcance pactadas.
- Representación transparente en PRINCE2
- La metodología no impone un formato único; por el contrario, alienta al equipo a elegir la representación visual más transparente, lo que convierte al burndown en una de las opciones más frecuentes cuando se emplean timeboxes.
- Scrum: práctica complementaria universal
- El gráfico de burndown no está incluido entre los artefactos oficiales de la Guía de Scrum (Product Backlog, Sprint Backlog e Increment), pero se ha consolidado como una práctica complementaria prácticamente universal.
- Burndown en proyectos híbridos
- En entornos híbridos donde conviven fases predictivas y paquetes de trabajo iterativos, el burndown coexiste con las estructuras de desglose del trabajo y los cronogramas de hitos: se aplica a los entregables ágiles, mientras que los componentes predecibles se gestionan mediante técnicas de valor ganado.
Perspectiva de la Gestión de Proyectos Orientada al Valor Empresarial (BVOP)
La Gestión de Proyectos Orientada al Valor Empresarial (BVOPM) aporta una lectura particular del gráfico de burndown, alineada con su obsesión por la entrega continua de valor y la eliminación del desperdicio. El burndown chart en BVOPM puede utilizarse como un indicador complementario que revela síntomas de “daño de proceso”, un concepto central en este marco que describe el perjuicio invisible que las prácticas ineficientes causan en la organización. Por ejemplo, un burndown que muestra un descenso muy errático o estancamientos prolongados sin una explicación técnica clara podría estar señalando microinterrupciones, dependencias mal gestionadas o sobrecarga cognitiva en el equipo, formas todas ellas de daño de proceso que BVOPM busca erradicar de forma proactiva.
BVOPM también introduce el seguimiento de puntos de valor de negocio (Business Value Points), que cuantifican la contribución de cada entrega a los objetivos estratégicos. En este contexto, el burndown tradicional —centrado en el esfuerzo restante— se enriquece al cruzarlo con la métrica de valor. Mientras el burndown advierte que el volumen de trabajo pendiente se reduce a buen ritmo, los puntos de valor de negocio confirman si ese esfuerzo se está traduciendo realmente en funcionalidades que los stakeholders consideran prioritarias. Una desconexión entre ambas curvas se interpreta en BVOPM como una señal de que el equipo podría estar cayendo en el desperdicio por perfeccionismo o en la sobreproducción de características de bajo impacto, dos de las categorías de muda que la metodología clasifica explícitamente.
Aplicación práctica del gráfico de burndown en equipos y organizaciones
En la operativa diaria, los equipos ágiles cuelgan el gráfico de burndown en radiadores de información, ya sea en formato físico o en paneles digitales accesibles para todos los miembros. El Scrum Master, o la persona que facilite la iteración, toma el dato de trabajo pendiente al cierre de cada jornada y actualiza el punto correspondiente. Lo relevante no es el dato puntual, sino la tendencia que emerge tras varios días. El uso del gráfico de burndown en equipos ágiles trasciende la mera comunicación de estado: se convierte en un detonante de conversaciones cruciales durante la reunión diaria, cuando los desarrolladores observan que la línea real se aplana y necesitan expresar bloqueos o pedir ayuda sin esperar a la retrospectiva.
En organizaciones grandes que ejecutan programas con varios equipos, los burndowns se agregan a nivel de release o de producto para ofrecer una visión consolidada a los patrocinadores. Estos gráficos agregados requieren precaución, porque ocultan las diferencias de ritmo entre equipos y pueden llevar a falsas conclusiones si algún equipo infla sus puntos de historia o usa criterios de estimación dispares. Por eso, muchas organizaciones prefieren mostrar burndowns por equipo y complementar la vista de programa con otros artefactos como los mapas de dependencias o los diagramas de flujo acumulado.
Los equipos que practican Kanban también han adaptado el concepto de burndown, aunque su naturaleza no iterativa hace que el enfoque temporal fijo sea menos natural. En estos casos, se utiliza a menudo un gráfico de envejecimiento del trabajo en curso o un diagrama de flujo acumulado para monitorizar la velocidad de finalización. No obstante, algunos profesionales generan burndowns sobre una ventana de tiempo móvil, por ejemplo los últimos treinta días, para obtener una imagen de cómo disminuye el trabajo pendiente total. Esta hibridación muestra que el principio de quemar trabajo restante es suficientemente flexible como para amoldarse a distintos contextos, siempre que el equipo entienda qué está midiendo exactamente.
Claves del burndown en la práctica
- Actualización diaria y tendencia
- El Scrum Master registra el trabajo restante al cierre de cada jornada, y la trayectoria que surge de varios días consecutivos revela patrones mucho más reveladores que una única medición aislada.
- Detonante de conversaciones
- En la reunión diaria, una línea real que se estanca indica bloqueos y anima a los desarrolladores a comunicar impedimentos o a solicitar ayuda de inmediato, sin necesidad de esperar a la retrospectiva.
- Agregación con precaución
- Los burndowns agregados por release o producto ofrecen una visión consolidada para los patrocinadores; no obstante, pueden disimular divergencias entre equipos y generar conclusiones engañosas.
- Adaptación a Kanban
- En equipos Kanban, las ventanas de tiempo móviles, como los últimos treinta días, permiten observar la evolución del trabajo pendiente total e identificar tendencias de mejora sin necesidad de iteraciones fijas.
Limitaciones, trampas comunes y conceptos erróneos
Un error frecuente es tratar la línea ideal como un compromiso contractual y castigar al equipo si la línea real no la sigue fielmente. Los errores comunes del gráfico de burndown nacen de la confusión entre herramienta de inspección y mecanismo de rendición de cuentas punitiva. Cuando los directivos exigen que la línea real se ajuste a la ideal sin considerar las razones de la desviación, el equipo puede verse tentado a manipular las estimaciones, a declarar trabajo completado antes de que realmente lo esté o a resistirse a reportar impedimentos. Todo ello destruye la transparencia que el burndown pretende fomentar y lo convierte en un termómetro estropeado.
Otra limitación relevante reside en la incapacidad del gráfico para distinguir entre trabajo valioso y trabajo simplemente terminado. Un burndown puede descender satisfactoriamente mientras el equipo entrega funcionalidades que nadie usará, o mientras acumula deuda técnica al acelerar artificialmente el cierre de tareas sin las validaciones adecuadas. Por eso los profesionales experimentados nunca miran el burndown de forma aislada, sino que lo cruzan con métricas de calidad, encuestas de satisfacción de los usuarios y, en entornos avanzados, con gráficos de valor entregado como el burnup chart.
Además, el gráfico de burndown no comunica cambios en el alcance de la iteración. Si durante el sprint se añade una historia urgente, el trabajo pendiente total aumentará, y la línea real podría incluso subir, algo que visualmente puede interpretarse como un retroceso. A menos que el equipo anote este evento sobre el propio gráfico, las partes interesadas que lo revisen días después carecerán del contexto necesario para comprender la ruptura de la tendencia. La práctica de anclar el burndown con anotaciones de eventos significativos —como la llegada de un requisito regulatorio o la ausencia de un miembro clave del equipo— es una costumbre que separa el uso maduro del uso superficial de este artefacto.
Relación con otros artefactos y métricas de seguimiento
La comparación más inmediata es la que enfrenta al burndown con el burnup chart. Ambos comparten el eje temporal, pero el burnup representa dos líneas ascendentes: el trabajo total planificado y el trabajo completado hasta la fecha. Las diferencias entre burndown y burnup no son meramente estéticas; el burnup tiene la ventaja de mostrar explícitamente si el alcance total ha variado a lo largo del tiempo, algo que el burndown oculta salvo que se recalcule manualmente. Por ello, en proyectos donde el backlog cambia con frecuencia, los gestores experimentados prefieren el burnup para las revisiones con stakeholders, mientras reservan el burndown para la inspección interna del equipo dentro de un sprint con alcance estable.
El gráfico de burndown también se distingue del diagrama de flujo acumulado, que muestra la cantidad de trabajo en cada estado del flujo a lo largo del tiempo. Mientras el burndown responde a la pregunta “¿cuánto queda por hacer?”, el diagrama de flujo acumulado ayuda a responder “¿dónde se acumula el trabajo y cuánto tarda en fluir de un lado a otro?”. Ambos comparten la filosofía de transparencia lean, pero operan en niveles diferentes: el burndown tiene una orientación hacia el resultado final, y el flujo acumulado hacia la salud del sistema de producción.
La relación entre el burndown y la velocidad del equipo es bidireccional. La velocidad —la media de puntos de historia completados por sprint— se calcula a partir de la pendiente real de los burndowns históricos. A su vez, un burndown de sprint se dibuja tomando como referencia el objetivo de velocidad comprometido. Si la velocidad real del equipo varía mucho de un sprint a otro, los burndowns dejarán de ser comparables entre sí, y cualquier previsión basada en ellos quedará en entredicho. La estabilización de la velocidad es, de hecho, uno de los objetivos colaterales que los equipos persiguen al analizar consistentemente sus burndowns en las retrospectivas.
Por último, conviene aclarar la convivencia del burndown con la gestión del valor ganado en proyectos híbridos. El valor ganado se apoya en el coste, el cronograma y el alcance, y utiliza métricas como el CPI y el SPI. Un burndown basado en horas de esfuerzo puede traducirse a lenguaje de valor ganado calculando el trabajo remanente en términos monetarios o de jornadas de trabajo, pero la correspondencia no es directa porque el burndown carece de la noción de línea base de coste. En entornos híbridos, algunos equipos de programa utilizan ambos conjuntos de métricas, aplicando el burndown para los paquetes de trabajo ágiles y el valor ganado para los componentes predictivos, y luego los consolidan mediante informes integrados.
Puntos clave de métricas de seguimiento
- Burndown versus burnup
- El gráfico de burndown representa la reducción del trabajo pendiente a lo largo del tiempo, mientras que el burnup superpone dos líneas ascendentes: el alcance total acumulado y el trabajo realmente finalizado, ofreciendo una visión más completa del progreso.
- Visibilidad del cambio de alcance
- El burnup muestra de forma transparente cualquier ampliación o reducción del alcance a medida que el proyecto avanza, a diferencia del burndown, que enmascara estas variaciones a menos que se recalcule la línea base de trabajo restante.
- Selección según la audiencia
- Cuando el backlog evoluciona con frecuencia, los responsables de proyecto utilizan el burnup en las reuniones con stakeholders para explicar los cambios de alcance, mientras que el burndown se aplica internamente en sprints con alcance fijo para monitorizar el ritmo diario del equipo.
- Burndown frente a flujo acumulado
- El diagrama de flujo acumulado revela la distribución del trabajo en cada fase del proceso, lo que permite identificar cuellos de botella, mientras que el burndown se centra en el avance hacia la meta y el CFD evalúa la estabilidad y previsibilidad del sistema de entrega.
- Límites y uso híbrido
- La elevada variabilidad en la velocidad del equipo reduce la fiabilidad de los burndowns y dificulta la extrapolación a métricas de valor ganado al carecer de una línea base de coste; en contextos híbridos se integran ambos enfoques para compensar estas limitaciones.
Tendencias actuales y evolución del concepto
Con la madurez del movimiento ágil, ha crecido un sano escepticismo hacia el burndown como único oráculo del progreso. Cada vez más organizaciones complementan este gráfico con técnicas probabilísticas de previsión, como las simulaciones de Monte Carlo, que proyectan fechas de finalización a partir de los datos históricos de flujo sin depender de una línea ideal arbitraria. La evolución del gráfico de burndown en proyectos ágiles apunta hacia una integración en cuadros de mando más ricos, donde el burndown convive con el control estadístico de procesos, los diagramas de dispersión de fechas de entrega y los mapas de dependencias. El burndown no desaparece, pero pierde el protagonismo exclusivo que tuvo durante la primera década de Scrum.
Otra corriente significativa cuestiona la práctica de expresar el trabajo en puntos de historia, abogando por el conteo directo de elementos de trabajo o por la estimación en horas con buffer. Esta discusión impacta de lleno en el diseño del burndown, porque modifica lo que representa el eje vertical. Algunos equipos han probado con burndowns que miden el número de historias de usuario no terminadas, un enfoque que simplifica la actualización diaria pero sacrifica la granularidad que ofrecen los puntos de historia cuando las historias varían mucho de tamaño. La solución no es única, y cada contexto de negocio debe decidir qué unidad hace que el gráfico sea más útil para la toma de decisiones, y no solo más cómodo de dibujar.
En paralelo, la inteligencia artificial aplicada a herramientas de gestión de proyectos empieza a ofrecer alertas automáticas cuando la pendiente del burndown se desvía significativamente de patrones históricos, e incluso propone ajustes de sprint basados en correlaciones con métricas de calidad o de rotación de equipo. Esta automatización, aunque prometedora, no debe reemplazar el diálogo humano que el burndown está llamado a provocar. La verdadera potencia del gráfico reside en la conversación que inspira, no en el dato que exhibe. Cuando un equipo mira la línea real por encima de la ideal y se encoge de hombros porque ya ha delegado el análisis en un algoritmo, se ha perdido el propósito original de transparencia y responsabilidad colectiva que dio origen al burndown chart hace más de treinta años.
