The Burndown Chart is a graph showing the amount of work remaining in a sprint over time, plotted against an ideal diagonal line that represents steady progress — a line so optimistic, so perfectly linear, so serenely diagonal that it could only have been drawn by someone who has never built software.
The ideal burndown is a straight line from top-left (all the work) to bottom-right (no work). This assumes that work is completed at a constant rate, that no new work is added, that no work is discovered to be larger than estimated, and that the team does not spend Days 1-3 in meetings about what to build rather than building it.
The actual burndown looks like an EKG readout: flat, flat, flat, sudden drop, flat, spike (scope added), flat, frantic descent on the last day, and a final position that is either at zero (the team killed themselves) or halfway down (normal).
The gap between the ideal line and the actual line is the gap between the plan and reality. The chart dutifully records this gap every day. Nobody is surprised by the gap. Everyone is required to look at it.
The Sideways Burn
The most common burndown shape is sideways — the line neither rises nor falls for days at a time, then lurches in one direction. This happens because:
- Days 1-2: Sprint planning was yesterday. The team is still reading the stories. Nothing is “done” because nothing has been started. The line is flat.
- Days 3-5: Work is in progress. Pull requests are open. Reviews are pending. Nothing moves to “done” because the Definition of Done requires review, and the reviewer is also in progress on their own work. The line is flat.
- Day 6: Three PRs are merged simultaneously. The line drops sharply. The Scrum Master exhales.
- Day 7: A production incident pulls two developers off sprint work. A new story is added. The line goes up. The chart is now burning upward, which is not a word anyone wants to use in a standup.
- Days 8-10: Frantic completion. Stories are closed. Acceptance criteria are loosely interpreted. The line descends. It does not reach zero, but it reaches “close enough to discuss in the retrospective without shame.”
The burndown chart records all of this faithfully. The burndown chart is the most honest document in Scrum. It is also the least consulted.
The Lifelog Burndown
In the lifelog, the burndown chart was replaced by a single number: tickets closed today.
“Twenty tickets on March 2nd. Eight before lunch on March 3rd. Ten on March 4th.”
— The Caffeinated Squirrel, counting, The Idle Factory, or The Morning the Backlog Ran Out of Ideas
No chart. No ideal line. No comparison between plan and reality. Just: how many things got done? The number told the whole story. The chart would have added axes, a diagonal, and the illusion that the work was predictable. The number admitted it wasn’t.
The Squirrel wanted a dashboard. The Squirrel always wants a dashboard. The number was the dashboard. It just didn’t have enough axes to satisfy a creature that believes all data improves with visualization.
Why It Persists
The burndown chart persists because it answers a question managers need answered: “Are we on track?” The answer is always “sort of” — which is not satisfying but is accurate, and the chart provides a visual representation of “sort of” that looks more rigorous than saying it out loud.
The chart also provides comfort. A downward-trending line — even an erratic one — suggests progress. Progress suggests control. Control suggests the sprint is working. The chart is a security blanket drawn on a whiteboard.
The best burndown chart is the one nobody looks at because the team is shipping and everyone can see it. The worst burndown chart is the one updated daily by a Scrum Master who spends more time maintaining the chart than the team spends on the work the chart is tracking.
