Azure DevOps Burndown Chart: Find and Read It

A sprint burndown chart answers one question every day of the sprint: are we on course to finish what we planned? Azure DevOps can show you one without any extra tooling. This guide covers how to get the built-in burndown, what to check before you trust it, how to read the common shapes, and where teams usually want something more.

What a sprint burndown chart shows

A burndown plots the work remaining in a sprint against time. The vertical axis is the amount of work left, either a count of work items or a sum of a numeric field such as story points or remaining hours. The horizontal axis is the days of the sprint. Most burndowns also draw an ideal line, a straight diagonal from the starting total on day one to zero on the last day, so you can see whether you are ahead or behind the pace that would finish everything on time.

Getting a burndown with built-in Azure DevOps features

Azure DevOps ships its own burndown and burnup reporting, so you do not need to install anything to start. There are two places to look.

The sprint analytics view. From your team in Boards, open the sprint and look for the analytics or burndown view for that iteration. It charts the sprint on its own, based on the iteration dates you have set for the team.
The dashboard widgets. Azure DevOps has Burndown and Burnup widgets in the dashboard widget catalog. Add one to a team dashboard, then configure it for the team, the iteration, and the measure you want to burn down. Typically you choose between a count of work items and a sum of a field, for example story points.

Exact menu names and options change from time to time, so treat the steps above as a map rather than a click-by-click script, and check Microsoft documentation for the current layout. The built-in charts use the Analytics service, so if a chart is empty or missing, confirm with your organisation administrator that Analytics is available for your project.

Set up the sprint so the chart is worth reading

Most disappointing burndowns are caused by setup, not by the team. Before you draw conclusions, check these basics.

Iteration dates are set. The chart cannot draw an ideal line without a start and end date for the sprint.
Work items are assigned to the iteration. Anything sitting in the backlog or in another sprint will not appear.
Estimates exist. If you burn down on story points or remaining work, items with no value contribute nothing. If half your items are unestimated, count-based burndown is more honest.
States are updated as work happens. A chart can only show completion when someone moves the item to Done. Batch updates on the last day produce a cliff at the end that says more about habits than about delivery.
The team agrees what Done means. Otherwise the line drops when an item is closed, not when it is actually finished.

How to read the shape

The line matters less than its shape. These are the patterns worth recognising, along with what they usually point to.

Flat, then a steep drop at the end. Work is being started together and finished together, or updated in bulk late. Smaller items and daily state updates usually fix it.
Line stays above the ideal for the whole sprint. The plan was optimistic, or capacity was lower than assumed. One sprint is a signal; three in a row is a planning problem.
Line drops below ideal early, then flattens. Estimates may have been generous, or the easy items were done first and the hard ones are still waiting.
The line goes up mid-sprint. Work was added after the sprint started. That is not a failure by itself, but it should be a decision someone made on purpose.
A flat line for several days. Either the team is blocked, or nobody is updating states. Both are worth a conversation at standup.

The scope problem: burndown hides added work

A classic burndown has one weakness. When work is added mid-sprint, the remaining total goes up, and completed work and added work partly cancel out. A team can finish a lot and still show a flat line, or add scope and quietly finish fewer of the original commitments than the chart suggests. This is why many teams prefer a burnup view, where completed work rises toward a separate scope line. Added scope moves the scope line instead of disturbing the progress line, so you can see both what was done and how much the target moved.

Where Agile Analytics adds to the built-in chart

Agile Analytics is an Azure DevOps extension that runs inside your own organisation and reads your existing Boards data. It does not replace the built-in charts, and if a single team only needs a basic burndown, the native tools are a reasonable answer. Where it helps is the questions a burndown alone does not settle.

Scope is a separate line. The Sprint Burndown view is drawn as a burnup, with three lines: Scope, Ideal, and Completed. Scope added mid-sprint moves the Scope line, so it is visible rather than absorbed.
Items or story points. You can switch the chart between counting items and summing story points, which is useful when only some teams estimate.
A summary strip under the chart. It shows committed, done, remaining, scope added, completed by today, and ideal by today, plus how far ahead of or behind the ideal completion you are.
Commitment reliability over time. Sprint Summary and Delivery Signals show commitment reliability, scope churn, and carryover across sprints, so one odd sprint is not mistaken for a trend.
A forward view. The Sprint Forecast dashboard widget runs a Monte Carlo forecast for the next sprint from your own history, giving the number of items the team completes at 85% and 50% confidence.

Burndown is a symptom, not a diagnosis

A burndown tells you that a sprint is off track. It rarely tells you why. If the shape keeps showing late drops or rising scope, the cause is usually upstream: stories too large to finish in a few days, work entering the sprint before it is ready, or too many items in progress at once. Reducing carryover and tracking commitment reliability across sprints is where the pattern turns into something you can act on.

Burndown chart questions

Short answers to the questions teams ask most often.

Does Azure DevOps have a burndown chart?

Yes. Azure DevOps includes sprint burndown reporting and dashboard widgets for burndown and burnup. They rely on the Analytics service, and they need iteration dates and work items assigned to the sprint.

Should I burn down on story points, hours, or item count?

Use whichever your team updates consistently. Story points suit teams that estimate every story. Remaining hours suit teams that plan at task level and update them daily. Item count is the safest choice when estimates are patchy, provided items are of a similar size.

Why does my burndown go up during the sprint?

Work was added after the sprint started, or an estimate was increased. A burnup chart with a separate scope line makes that visible without disturbing the progress line.

Is a burndown chart enough to forecast delivery?

It shows the current sprint only. For planning the next one, look at how much your team has completed over several recent sprints and how reliably it met its commitments.

Try it on your own sprints

The extension installs from the Visual Studio Marketplace and starts a 30-day trial on install, with no credit card. It reads your existing sprint history, so the burndown and commitment views work on real data as soon as you open them. See the pricing page for plans after the trial.

Related: Pricing

Azure DevOps Burndown Chart: How to Set One Up and How to Read It Honestly