Burndown vs. Cumulative Flow Diagrams

---

Two Different Pictures of the Same System

The burndown chart and the cumulative flow diagram (CFD) both visualize work over time, but they answer different questions. The burndown shows "how much work is left in this sprint?" The CFD shows "how is work moving through our system?"¹

The two charts have very different shapes, very different uses, and very different failure modes. Choosing between them is less about which is correct and more about what the team is trying to see.

The Burndown

A burndown chart plots remaining work (in points or items) on the y-axis against time on the x-axis. The line starts at the sprint's total committed work and trends down toward zero. An ideal-trajectory diagonal serves as a reference. The chart's appeal is its simplicity: at a glance, are we ahead, behind, or on track?

What burndowns do well

• Make sprint progress visible at-a-glance to the team and stakeholders.
• Trigger early conversations when the team is clearly off-track by day three.
• Provide a familiar reference point for teams new to agile.

How burndowns fail

• Sprint-scoped only. A burndown shows nothing about work outside the current sprint. Aging items, bottlenecks, and system-level patterns are invisible.
• The "all done on day 10" pattern. Most real burndowns are flat until the last day, when they crash to zero. The chart suggests this is fine; the reality is large stories finishing in a rush.
• Treated as a commitment vs. actual chart. Stakeholders read burndowns as performance indicators. The team starts shaping work to make the chart look right.
• Hides work-in-progress. A burndown that goes down might mean items finished, or it might mean items got descoped. The chart doesn't distinguish.

The Cumulative Flow Diagram

A CFD plots stacked areas for each stage of the work (e.g., Backlog, In Progress, Review, Done) over time. The thickness of each band shows how much work is in that stage at each point. The chart's information density is much higher than a burndown's.

What CFDs do well

• Surface system bottlenecks. A band that's growing thicker over time means work is piling up in that stage.
• Show cycle time geometrically. The horizontal distance from "started" to "done" for the same area shows how long work takes.
• Reveal WIP trends. If the in-progress band is widening, the team is accumulating WIP — a leading indicator of slowdown.
• Cross-sprint visibility. CFDs span weeks or months, exposing patterns burndowns cannot.

How CFDs fail

• Steep learning curve. Reading a CFD requires more interpretive skill than reading a burndown. New stakeholders bounce off it.
• Easily mistaken for status. A "nicely growing Done band" can look like progress when it actually shows steady throughput on a backlog that's also growing.
• Sensitive to story-size variation. If item sizes vary wildly, the CFD becomes noisy.
• Drives metric games. Teams who learn what a healthy CFD looks like can manipulate it (e.g., split work to keep flow steady).

The Choice Depends on the Question

Burndowns answer one question well: are we on track for this sprint? They fail at almost every other question. CFDs answer a broader range of questions but require more sophistication to read. The right chart depends on what the team is trying to learn:

• Sprint review with stakeholders? Burndown. Familiar, simple, immediate.
• System health diagnosis? CFD. Bottlenecks, WIP trends, and cycle-time variation all visible.
• Long-range forecast? Neither — use throughput-based Monte Carlo forecasting instead.
• Team retrospective? CFD plus a cycle-time scatter plot together produce richer reflection material than burndowns alone.

The Modern Stance

Most agile-mature organizations have moved away from burndowns as their primary chart, partly because the burndown's information value is so low and partly because it gets misused as a performance indicator. CFDs (and cycle-time scatter plots) have largely replaced them in the literature.² The teams still leading with burndowns are usually doing so because that's what the tool defaults to, not because the burndown is the best fit for what they want to see.

Coaching Tips

Add a CFD alongside the burndown.

Don't remove burndowns abruptly — layer the CFD next to it for a few sprints. Most teams switch on their own once they see what each shows.

Teach CFD reading explicitly.

Five minutes in a retro showing the team how to read their own CFD pays off for months. Don't assume it's self-evident.

Watch the in-progress band.

If it's widening, WIP is climbing. The CFD shows this before any other metric catches it.

Don't put either on an exec dashboard.

Neither chart belongs in upward reporting. Translate to outcomes for stakeholders. Use the operational charts inside the team.

Watch for the day-10 cliff.

A burndown that crashes to zero on the last day is a story-size problem, not a planning problem. Surface it.

Pair the CFD with a cycle-time chart.

Together they tell a story neither tells alone. The CFD shows the flow shape; the scatter shows the outlier items.

Summary

Burndowns are simple, familiar, and limited. CFDs are richer, more diagnostic, and harder to read. Neither is universally better — they answer different questions. Teams stuck in burndown culture are usually stuck because the tool defaulted to it; teams that have invested in reading CFDs find that the additional sophistication pays back quickly in better system-level decisions. The wrong move is to treat either chart as the answer to all questions — and the right move is to know which question the team is trying to answer before picking the chart.

Back to The Great Agile Debates