Concept 5 of 5

Burndown, burnup and cumulative flow

2 questions test this

Scrum requires none of these, and it does name them. In the section on the Sprint the 2020 Guide says that various practices exist to forecast progress, like burndowns, burnups or cumulative flows, that they have proven useful, and that they do not replace the importance of empiricism. That is the whole of what Scrum has to say about charts.

That matters twice. On an exam, any answer claiming Scrum mandates a chart is wrong. In practice it means the choice is yours, and the three differ in what they are capable of hiding.

The burndown chart

Work remaining on the vertical axis, time on the horizontal. One line, falling towards zero.

WorkleftDay 10Day 1idealactual

The flat stretch from day four to day seven is the whole value of the chart and also its limit. It says work remaining stopped falling. It cannot say whether the team was blocked, or was finishing items while new ones arrived.

It is cheap to draw and immediately legible, which is why it spread. Inside a Sprint, where scope is largely settled, it does an honest job of showing whether the Sprint Goal is still reachable.

Across a release it becomes misleading, because the one thing it cannot show is the thing most likely to be happening, which is scope changing underneath the line.

The burnup chart

The same idea split into two lines. One tracks work completed, climbing. The other tracks total scope, which is free to move.

Itemstotal scopecompletedscope addedscope added

The gap between the lines is what remains. Here the team is completing work steadily and the finish line keeps moving, which a burndown would have shown as a team falling behind.

This is the more honest chart for anything longer than a Sprint, because it separates two questions a burndown fuses into one. Is the team delivering, and is the scope stable. A stakeholder looking at a burnup can see that a slipping date is a scope decision rather than a delivery problem, which is a conversation worth having and one the burndown quietly prevents.

The cumulative flow diagram

Bands stacked over time, one per state the work passes through. The height of each band is how many items are sitting in that state on that day.

DoneIn reviewTo doItemsThe review band widens, so work is queueing there

Every band should stay roughly constant in height. One that widens is a queue forming in front of a bottleneck, visible here days before anybody would have noticed it in a standup.

It carries more than the other two, and it needs reading rather than glancing at.

The slope of the top edge is the rate work arrives. The slope of the bottom edge is throughput, the rate work finishes. When arrival outruns throughput the total height grows and the system is accumulating work in progress it cannot clear.

Measure horizontally between the top and bottom edges and you get approximate cycle time. Measure vertically and you get work in progress. That the two are related by throughput is Little's Law, and it is the reason limiting work in progress shortens delivery time without anybody working faster.

Which one to reach for

QuestionChartWhy
Is the Sprint Goal still reachableBurndownScope is largely fixed inside a Sprint, so one line is enough
Will we make the release dateBurnupSeparates a delivery problem from a scope decision
Why is everything taking so longCumulative flowShows where work is queueing rather than how much is left
What should we tell a stakeholderBurnupThe scope line makes the trade off visible without an argument

What none of them tell you

All three measure output. An item moving to Done raises the completed line whether or not anybody wanted the item, so a perfect burnup is entirely compatible with a product nobody uses.

They also invite the failure common to every visible measure, which is being optimised directly. A team asked to keep the burndown near the ideal line will split items smaller, defer the hard one, or record work as Done before it meets the Definition of Done. The chart improves and the Sprint does not.

Treat them as instruments for a conversation the Scrum Team is having with itself about how work is flowing. Whether the work was worth doing is a different question, answered at the Sprint Review and by the value measures that sit alongside these.

Common misconceptions

Scrum requires a burndown chart.

It does not. The 2020 Guide names all three in the section on the Sprint, and names them as practices that exist rather than as anything required, adding that they do not replace the importance of empiricism. A team may use any of them, none of them, or something else.

A flat burndown line means the team did nothing.

It means work remaining did not fall. The team may have completed five items while five more were added, which the chart cannot distinguish from an idle Sprint. That single blind spot is the reason burnups exist.

A cumulative flow diagram shows how fast the team is working.

It shows how work is distributed across states over time. The slope of the bottom band is throughput, the slope of the top is arrival rate, and the most useful reading is a widening band, which is queued work in front of a bottleneck rather than speed.

2 questions test this concept

A release burndown has stayed flat for three Sprints and the delivery manager concludes that the team has slowed down. The product owner knows the team finished work in every one of those Sprints while nine items were added to the release. Which chart would have shown what was actually happening, and what would it have shown?

  • AA burnup, because it plots completed work and total scope as two separate lines, so a rising scope line shows that the finish moved rather than that delivery slowed.
  • BA cumulative flow diagram, because the bands would show which state the extra work was sitting in.
  • CThe same burndown with the ideal line redrawn from the new total, because that restores the comparison.
  • DNo chart would help. The release should have had its scope frozen at the start so that the burndown stayed meaningful.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
Actionable Agile Metrics for Predictability, On flow measures and why cumulative flow beats a burndown for forecasting.
Book
Agile Estimating and Planning, On release burndowns and tracking against a changing scope.
Book
The Principles of Product Development Flow, On queues as the thing that actually determines delivery time.