Burndown Chart: How to Read It, What It Shows and When It Lies

The burndown shows how much work is still left relative to the time remaining. The line starts at the sprint's planned total and should get close to zero on the last day. Reading the chart means comparing the actual line with the ideal line and asking why they drift apart. The most common mistake is to look only at whether the line "is going down" and forget to ask what it's measuring.

This article describes the shapes the chart usually takes, what each one says about the sprint, and the mistakes that make the chart look good while the team is behind.

How the chart is built

The horizontal axis is the days of the sprint. The vertical axis is the remaining work, measured in points, hours, or number of tasks. Two lines appear:

• Ideal line: a straight line from the planned total on the first day to zero on the last. It's the reference for a steady pace.
• Actual line: what actually remained at the end of each day, as tasks are completed.

If the actual line is below the ideal, the team is ahead. If it's above, the team is behind. It seems simple, and it is: the difficulty is in interpreting the shape, not in reading the position.

The most common shapes

Shape	How it looks	What it usually means	What to do
Close to ideal	The actual line follows the straight line, with small deviations	Realistic planning and steady flow	Keep going. Note what worked for the next sprint
Behind	The actual line stays above the ideal and the gap between them widens	Scope too large for capacity, or blockers that haven't been dealt with	Talk about it at the daily, take items out of scope, or remove the blocker
Growing scope	The line goes up mid-sprint instead of only going down	New requests coming in after the start, or tasks that turned out bigger	Record the source of each addition and agree with the product owner on what comes out in exchange
Step at the end	The line stays nearly flat and plunges in the last days	Tasks are only closed at the end, or too much work in progress	Break work into smaller items, limit work in progress, and update status daily
Ahead too early	The actual line drops well below the ideal already in the first half	Inflated estimates, or easy items done first	Pull more items from the backlog and review how estimates are calibrated
Flat line	Nothing changes for days in a row	Team blocked, or status not being updated	Find out which of the two is the cause before drawing any conclusion

Behind: the deviation that accumulates

Being a day behind the ideal is normal. What deserves attention is the distance growing: the chart shows that the gap doesn't close on its own. The sooner you notice, the more options you have. On day four, you can pull an item without drama. On day nine, all that's left is explaining the delay.

Growing scope: the line that goes up

This is the most overlooked reading. A rising line isn't the team's fault: it's a sign that new work came in. It may be legitimate (an urgent problem), but it needs to be visible. Without a record, the team is held to a target that changed halfway through, and the conversation turns into defense. With a record, the question becomes "what came out so this could go in?"

Step at the end: the chart that looks like a staircase

When the line drops almost entirely in the last days, the chart isn't saying the team sped up. It's saying status is only updated on the eve of the review, or that many tasks stay "almost done" for days. The risk is real: if one of them gets stuck on the last day, what looked almost done becomes leftover for the next sprint.

When the burndown lies

The chart is faithful to what's recorded, not to what happens. When the record is bad, the chart becomes a comfortable fiction. Five situations come up often.

1. Measuring by number of tasks when they're very different sizes

If the sprint has 20 tasks, and one of them is worth more than the other 19 combined, completing 19 leaves the line almost at zero and the main work untouched. Use points, hours, or at least tasks of similar size. The care of breaking work into comparable pieces is explained in epic, user story, and task.

2. Closing a task to make the line go down

If the line is used as a way to hold people accountable, they learn to move the card without really finishing. The chart improves and quality gets worse. Agree on a clear definition of done (reviewed, tested, approved, published) and only count what meets it.

3. Re-estimating to make the numbers work

Lowering a task's estimate mid-sprint to make the line look good erases the delay from the chart, but not from the calendar. An estimate should only change when knowledge changes, and the change needs to be recorded.

4. Hiding new scope

Delivering an extra request without logging it in the sprint makes the team look slow: the work was done, but the line doesn't show it. It's the opposite of the previous case and just as misleading. All relevant work should be on the board.

5. Drawing conclusions from a short or isolated sprint

A one-week sprint with a holiday in the middle produces a crooked chart without anything having gone wrong. Look at the pattern across several sprints before changing the process. If three sprints in a row end with a step, the problem is flow, not bad luck.

Questions the chart helps answer

• Is the planning realistic? If sprints always end above the ideal, the team is committing to more than it delivers.
• Is work coming in from outside? A line that rises repeatedly points to requests coming in without going through planning.
• Is the flow continuous? Steps indicate delivery concentrated at the end.
• Are there blockers? A flat line for days is the question "what's getting in the way?" already formulated.

Notice that none of these questions is "who's behind?" The burndown measures the sprint, not the people. Used as a tool for individual accountability, it stops being used honestly.

Burndown, board, and flow: each answers a different question

The burndown answers "will we finish on time?" It doesn't answer "where is the work stuck?" or "how long does each item take?" For that, look at the status board and the flow metrics. Tasskee's flow page deals precisely with that reading, how long work spends in each stage, which complements the burndown.

If you're just starting with Scrum, the Scrum guide explains where the chart fits in the sprint cycle, alongside the daily, the review, and the retrospective.

A practical use per sprint

1. At the first daily, check that the planned total is correct and that all the planned work is on the board.
2. Mid-sprint, compare the actual line with the ideal. If the distance exceeds a fifth of the total, talk about pulling an item.
3. When the line goes up, note the source of what came in and agree on what comes out.
4. At the retrospective, use the chart's shape as a starting point: behind, step, growing scope? Each one leads to a different conversation.

The one-fifth threshold is a suggestion to spark the conversation, not a rule of the method. Adjust it to your team after a few sprints.

Summary

A good burndown is one that helps you decide early: pull an item, remove a blocker, renegotiate scope. A bad burndown is one that only confirms, on the last day, what everyone already felt. The difference lies less in the chart and more in the honesty of the record that feeds it.