Why the burndown chart misleads when agents build
Stefan-Iulian Tesoi · · 6 min read
Because a burndown chart counts work when it closes, and with coding agents work closes at review, days after the code exists. The line sits flat while finished changes wait for a reviewer, then drops in one afternoon. A cumulative flow diagram shows where the work is waiting, which is what the burndown was drawn to answer.
Nothing about the chart is broken. It measures the right thing for a team whose bottleneck was writing code, and that team stops existing once agents do the building.
What does a burndown chart measure once agents build?
The same thing it always measured: estimated work not yet accepted, plotted against the days left in the sprint. A sprint burndown starts at the committed total, say 40 points across 12 items, and steps down each time an item reaches Done. The ideal line is a straight diagonal to zero on the last day.
What changed is what sits between starting an item and closing it. When people wrote the code, most of an item's cycle time was the writing, so the line fell roughly as fast as the team worked. With a coding agent the writing takes minutes to an hour. The time now goes to code review, to a person running the change, and to the rework that review finds. None of that moves the line until the last step.
The Scrum Guide never required the chart. It names it as one option among three:
"Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows."
Most teams draw the burndown because it is the simplest of the three to keep up, which is a reason about effort, not about which question matters.
Why is the line flat and then a cliff?
Because agents finish code in batches and review accepts it in batches. An illustrative ten-day sprint of 40 points shows the shape:
| Day | Code written (points) | Accepted (points) | Burndown shows |
|---|---|---|---|
| 1 | 14 | 0 | 40 remaining |
| 2 | 26 | 0 | 40 remaining |
| 3 | 33 | 5 | 35 remaining |
| 6 | 38 | 8 | 32 remaining |
| 9 | 40 | 31 | 9 remaining |
| 10 | 40 | 37 | 3 remaining |
By the end of day two, 26 of the 40 points were written and the chart still read 40. On day six the sprint looked badly behind while its code was nearly finished. Then one review session on day nine accepted 23 points at once.
A flat line followed by a cliff means a queue formed in front of review and someone emptied it. Read the old way, the flat stretch says the team is stuck and the cliff says it caught up. Both readings are wrong. The building was never stuck, and the cliff is usually a reviewer approving several changes in a hurry near the end, which is when review is least careful.
That second effect is the expensive one. A chart that rewards the drop teaches a team to batch acceptance before the sprint review, and a batch approved in an hour is where a change that meets its criteria on paper slips through.
What does a cumulative flow diagram show instead?
Where work is waiting, day by day. A cumulative flow diagram stacks one band per board column, Ready, In Progress, In Review and Done, and plots how many items sit in each. A band that widens is a queue forming. In a sprint whose code is mostly written by day two and mostly accepted on day nine, the In Review band swells on day two and stays wide for a week, and anyone looking on day three books review time instead of chasing the agents.
The diagram also yields cycle time without extra tracking. The horizontal distance between the line entering In Progress and the line entering Done is roughly how long an item takes end to end. Little's Law ties the bands together: average cycle time equals work in progress divided by throughput. With 9 items in review and 3 accepted a day, a new item waits about three days for a reviewer, however fast the agents are.
In Laimonade, a coding agent's commits can carry an item as far as In Review and no further. A person accepts it, or Laimon, the product owner agent, closes it with the closure stamped as its own. That makes In Review the column where a sprint's real progress waits, which is why the sprint workflow keeps it separate from Done.
Is a burnup chart any better?
Somewhat. A burnup chart draws two lines, completed work rising toward total scope above it, so scope added mid-sprint shows as the top line moving rather than as missing progress. That fixes the burndown's oldest distortion.
It does not fix the new one. A burnup still counts accepted work, so it has the same flat stretch and the same cliff, rising instead of falling. It is a better chart for a stakeholder asking whether the commitment changed, and no better for a team asking why nothing has closed since Monday.
Which three numbers belong on the sprint board?
Numbers that move while the work moves. Sprint progress tracking with agents works better with three of them than with any single line:
- Items waiting in review, and the age of the oldest. Nine items is a scheduling problem. One item four days old is a forgotten one.
- Median cycle time from Ready to accepted, per sprint. It falls when items are specified well and rises when review keeps sending work back.
- Items reopened after acceptance. A cliff followed by reopenings is the batch-approval failure, measured.
These overlap with the coding agent metrics worth tracking over a quarter, and they replace velocity as the planning input in sprint planning with agents. Points can stay on the items as a measure of specification risk rather than effort, the case made in whether story points still work.
Frequently asked questions
Should the team stop drawing a burndown?
Not necessarily, but it should stop reading the chart as a measure of building. Keep it if stakeholders expect it, and put a cumulative flow diagram beside it so the flat stretch has an explanation. Drop it once nobody makes a decision from it. A chart drawn every day and acted on never is a habit, not a measurement.
How do you show scope added mid-sprint honestly?
With a burnup chart, or with a separate scope line on whichever chart the team keeps. Added items raise the total on the day they arrive and removed items lower it. A burndown that silently absorbs new scope makes a team look as if it is falling behind when the commitment was the thing that changed.
What does a healthy cumulative flow diagram look like?
Bands of roughly constant width rising together, with Done growing steadily rather than in steps. The In Review band stays thin: a few items, none of them old. A band that keeps widening is a queue nobody is working, and a Done band that climbs in stairs is review being done in batches.