Burndown Chart: How to Read One and When It Lies

A burndown chart shows how much work is left in a Sprint or a release, day by day, against a straight line from the starting total to zero. If the actual line runs above the straight one, you are behind; below it, ahead; flat, nothing is being finished. That is all it shows, and the limits matter as much as the reading: a burndown counts remaining work, not value delivered, it hides scope added and removed unless the tool draws a separate scope line, and it is only as accurate as the last time someone updated an estimate. Read it as a prompt for a conversation, not as a forecast you can take to a customer.

What a burndown chart plots

The Agile Alliance glossary↗ (opens in a new tab) defines it as a large graph relating the quantity of work remaining, on the vertical axis, to the time elapsed since the start of the project, on the horizontal axis. It credits Ken Schwaber with inventing it around 2000 as part of a simple tool kit for Scrum teams. There are two common scopes: a Sprint burndown, which covers one Sprint, and a product or release burndown, which covers a larger body of work over many Sprints.

• Horizontal axis: days, or Sprints for a release burndown.
• Vertical axis: work remaining, in whatever unit the team estimates in: story points, hours of remaining work, or simply the number of items.
• Ideal line: a straight line from the starting total on day one to zero on the last day. Some tools skip weekends and days off.
• Actual line: the real total remaining at the end of each day.

The chart is not part of Scrum’s rules. The Scrum Guide↗ (opens in a new tab) mentions it only in passing: “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows.” It is a habit teams adopted, which is worth remembering when it stops being useful.

Ideal line vs actual line: a worked example

A four-person team starts a ten-day Sprint with 40 story points. The ideal line drops 4 points a day. Here is what actually happened:

Day   Ideal   Actual   Note
0     40      40
1     36      40       Nothing finished yet
2     32      40       Still nothing
3     28      35       First story done
4     24      37       5-pt story added mid-Sprint (+5), 3 done
5     20      30
6     16      26
7     12      21
8     8       13
9     4       8
10    0       3        One 3-pt story carried over

Three things are visible. The flat start on days one and two is normal when stories are large: nothing counts as done until a whole story is. The bump on day four is scope added, and a burndown shows it only as the line going up, which looks the same as a bad estimate. And the finish at 3 rather than 0 tells you one story did not make it, not why. Each of those is a question for the Daily Scrum or the Retrospective, not an answer.

How to read the shapes

• Flat for several days, then a cliff: stories are too big, or work is being finished but not marked done until the end. Split the work smaller.
• A staircase: updates happen every few days rather than daily. Microsoft’s documentation for Azure Boards notes this is usual when team members update their items only once a week or every few days.
• Consistently above the ideal line: the Sprint was overcommitted, or something is blocking. Decide what to drop early rather than on the last day.
• Well below the ideal line early: the Sprint was undercommitted, or estimates were padded.
• Line going up: work was added or re-estimated. A plain burndown cannot tell you which.
• Perfectly on the ideal line every day: be suspicious. Real work is lumpy, and a perfect line often means people are updating the numbers to match the line.

Reading scope creep

Scope change is where a basic burndown misleads most. Adding five points and finishing five points on the same day leaves the line flat, so the chart says “no progress” when the team did a full day’s work. Removing a story quietly makes the line drop, so the chart says “great progress” when nothing was built. The Agile Alliance lists this as the first limitation: a burndown reflects work completed but not changes in the total scope.

Tools handle it with a separate scope line. The Azure DevOps sprint burndown report↗ (opens in a new tab) shows a Total Scope Increase figure and a Scope line for work added after the Sprint started. Jira’s burndown counts adding subtasks to items in an active Sprint as a scope change. If your chart has no scope line, write scope changes down in the Sprint notes on the day they happen, or you will not be able to explain the chart at the Review.

When a burndown chart lies

• It measures effort estimates, not value. Burning 40 points of the wrong work looks identical to burning 40 points of the right work.
• It hides which items are done. Ten points left could be one untouched story or five nearly finished ones.
• Partial work counts as nothing, or as too much. Hour-based charts reward reporting hours burned; point-based ones ignore a story that is 90% done.
• Tool rules change what counts. Atlassian’s Jira documentation↗ (opens in a new tab) notes that story points on subtasks are not included in the burndown, only those on parent items, and an item counts as done only in a status mapped to the board’s right-most column.
• Stale updates. If nobody updates remaining work, the chart shows the plan, not the Sprint.
• It becomes a target. Once people are judged by the line, they bend the estimates to fit it.

Burndown vs burnup chart

A burnup chart turns the picture over: it plots work completed rising toward a total-scope line. Microsoft’s burndown and burnup guidance↗ (opens in a new tab) puts the difference simply: a burndown starts with the total planned work and graphs what remains, while a burnup tracks work as it is completed and should always trend upward. Because the scope has its own line, a burnup shows scope creep directly; the Agile Alliance describes the burn-up as the fix for exactly that blind spot.

• Use a burndown for a single short Sprint with stable scope, where the only question is “will we finish?”
• Use a burnup for a release or project where scope moves, where the question is “are we finishing faster than we are adding?”
• Use neither if you do not work in fixed iterations. A flow board has better measures, below.

A simple burndown chart template

Any spreadsheet can draw one. Use four columns and a line chart of the middle two:

A: Day         0, 1, 2 ... last day of the Sprint
B: Ideal       =start_total - start_total/sprint_days * A2
C: Remaining   type the real total left at the end of each day
D: Scope       total planned, updated when items are added or removed

Chart B and C as lines. Chart D too and you have a burnup-style scope line.

Azure DevOps sprint burndown chart not working

An empty or wrong Sprint burndown in Azure Boards is usually a setup gap rather than a bug. Microsoft’s documentation lists what the chart needs:

• Sprints scheduled with dates, and work assigned to the Sprint the chart is for.
• To burn down on Remaining Work: tasks defined for each backlog item and Remaining Work filled in and updated as work progresses.
• Parent items assigned to the same Sprint as their tasks; otherwise tasks can appear under another Sprint.
• Azure Boards turned on for the project; on Azure DevOps Server, the Analytics service installed and enabled.
• Area Path and Iteration Path values left alone: Microsoft warns that deleting or reconfiguring them causes irreversible data loss in burndown charts.

What a flow board shows instead

Teams that work from a continuous queue rather than in Sprints have no start total to burn down. The Kanban Guide↗ (opens in a new tab) asks them to track four measures instead: work in progress, throughput, work item age and cycle time. Together they answer the burndown’s question in a different way: not “will we hit zero by Friday?” but “how much is in flight, how fast do items finish, and which ones are getting old?” Cycle time vs lead time explains how to work those out, and Kanban vs Scrum covers when a flow approach suits better than Sprints.

Where fenbs fits

fenbs does not draw a burndown or burnup chart, and it has no sprints, due dates or story points. It is a kanban-style board with four lanes, To Do, Next Up, In Progress and Completed. The Insights panel above the board shows the current counts, open, urgent P1, In Progress and Completed, with the share completed; it counts only tasks that were actually built, not ones closed as duplicates or won’t fix. History records every move with who made it, a person or an AI assistant, and how long ago, so a team that wants a burnup can rebuild one by hand. If your team relies on generated Sprint burndowns, a dedicated Scrum tool will serve you better.