Few things are more frustrating on day three of a sprint than opening the burndown and finding an empty box. Public forum threads on this are easy to find, and they ask the same question in different words: why is my burndown chart empty? The chart is rarely broken, even when a thread is titled simply “Burndown chart is empty”. In most cases it is waiting for something the team never set up, or it is measuring something different from what the team assumed. This post goes through the documented causes, one at a time, and then covers how to read the numbers once the chart does show up.
First, know what the built-in chart measures
Azure DevOps has two sprint burndown charts, the Burndown Trend report on the sprint backlog Analytics tab and the Sprint Burndown dashboard widget. Both draw their data from the Analytics service. Both can burn down on a count of work items or on a sum of a numeric field such as Story Points, Effort or Remaining Work. Which one you picked decides what has to be filled in before anything appears. If you burn down on Remaining Work, only tasks with hours on them contribute. If you burn down on Story Points, only items with points contribute.
Related: Microsoft Learn: Configure and monitor sprint burndown
The checklist for an empty burndown
Microsoft lists three checks for an empty sprint burndown, and the surrounding documentation adds the rest. Work through them in this order, because the first ones are the most common.
- Are tasks assigned to the sprint the chart is showing? The chart follows the iteration path on each item. Work sitting in another iteration, or still in the backlog, does not appear.
- Do the tasks have Remaining Work? If you burn down on Remaining Work, a task with no hours has nothing to burn. This is the usual reason a sprint full of stories shows a flat, empty chart.
- Are the parent work items in the same sprint? Microsoft notes that if the parent is not in the sprint, the tasks might appear in another sprint associated with the parent item.
- Does the sprint have start and end dates? The chart needs a date range to draw an ideal line. Sprints are scheduled under the project and team iteration settings.
- Is Analytics available? The built-in burndown widgets depend on the Analytics service, and Boards must be enabled, so an administrator may need to check this.
- Did anyone change area or iteration paths? Microsoft warns that deleting Area Path values or reconfiguring Iteration Path values causes irreversible data loss in burndown charts.
Related: Microsoft Learn: Troubleshoot an empty burndown chart
Why moving items between sprints changes the story
A public forum question describes a team that moved its unfinished items to the next sprint, after which the old sprint burndown “shows 100% (even though we only finished 80% of the workitems)”. The documented behaviour points at the cause. In the built-in chart, Total Scope decreases when an item’s Iteration Path changes to another sprint. Items you move out stop belonging to that sprint, so the old sprint can end up looking better than the plan it started with. The chart is reporting the sprint as it now stands, which is not the sprint you planned. If you care about what was committed against what was delivered, look at carryover and commitment reliability over several sprints, not at one burndown.
Related: The public question (Stack Overflow) · Reducing sprint carryover in Azure DevOps
Why the ideal line looks wrong
The ideal trend is calculated from the number of work items (or the field total), the days in the sprint and the working days. Non-working days come from the team settings for working days and days off, so a wrong team calendar can skew the picture. The ideal line also assumes work finishes at an even pace, which almost no team does. Microsoft itself notes that because people tend to update items every few days, a staircase pattern is normal. Treat the ideal line as a rough pace marker, not as a target the team has failed when it misses.
The hours trap
Many burndown complaints are really complaints about hours. Teams that plan in story points and never enter task hours get an empty Remaining Work chart. Hours that are only updated now and then give a staircase instead of a smooth line, which is why Microsoft recommends updating Remaining Work daily or several times a week. The built-in chart can burn down on points or on item count, which sidesteps the problem when you choose it, but the choice is made per chart and it is easy to leave a widget on its default. A useful rule: pick the measure your team really updates every day, and burn down on that. For many teams that is simply whether an item is done.
What Agile Analytics does differently, and what it does not
Agile Analytics is an Azure DevOps extension that runs in your browser against your own organisation. Its sprint chart is a burnup, titled Sprint Burnup on the tile, with three lines: Scope, Ideal and Completed. It reads the team’s active sprint and can count either items or story points, with a toggle between the two. Because it counts completed items rather than hours, it does not depend on anyone entering Remaining Work. A few honest limits are worth knowing:
- It needs sprint start and end dates. If Azure DevOps has none for the sprint, the view says so instead of drawing a chart.
- It shows the current active sprint for the selected team, not a pick-any-past-sprint view.
- Scope added is detected from items created after the sprint began. An item that already existed and was moved into the sprint later is not counted as added scope, so it lands in the baseline.
- In Story Points mode, an item with no points gets a default weight based on its type, so unestimated work does not vanish from the chart. If points matter to you, estimate the work.
- It is available as a Dashboard tile named Sprint Burndown, which is hidden by default and can be switched on when you customise the Dashboard.
A burnup answers the scope question that a burndown blurs. Work added mid-sprint raises the Scope line, while Completed keeps its own line, so you can see how much was done and how far the target moved. The summary under the chart shows committed, done, remaining, scope added, completed by today and ideal by today. For the longer view, Sprint Summary and Delivery Signals show commitment reliability, scope churn and carryover across sprints, which is what a single burndown cannot tell you.
Related: Azure DevOps sprint reporting · Azure DevOps burndown chart guide · What belongs on a sprint health dashboard
Questions teams ask
Short answers to the most common follow-ups.
Why is my burndown empty when the sprint has stories?
Usually because the chart is set to Remaining Work and the tasks have no hours, or because the tasks are not in the sprint iteration. Switch the chart to count of work items, or add tasks with Remaining Work.
Does Agile Analytics need task hours?
No. Its sprint chart counts completed items, or story points if you switch the toggle, so it does not read Remaining Work.
Do I need Power BI to get a trustworthy burndown?
No. The built-in charts and Agile Analytics both work without it. Power BI is a good fit when you want to model data of your own.
Try it on a live sprint
Agile Analytics installs from the Visual Studio Marketplace and starts a 30-day trial on install, with no credit card. During the trial everyone in the organisation has full access, so you can open the sprint views on a real sprint and see whether they answer what the built-in chart did not. See the pricing page for plans after the trial.
Related: Pricing · Install guide