How Do You Create a Burndown Chart in Power BI?

How Do You Create a Burndown Chart in Power BI?

A burndown chart answers one question: is the remaining work falling fast enough to finish on time? It plots work left against time, and if the line is flatter than it should be, the sprint is in trouble and everyone can see it at a glance.

Power BI can draw that chart well. What it cannot do is draw it from the data most people hand it. There is no "burndown" entry in the visualizations pane, and more importantly, a burndown is a historical chart being built from a table that usually only holds the present. Get that part right and the chart is twenty minutes of work. Get it wrong and you will produce something that looks like a burndown and means nothing.

This guide covers the direct answer, why the data shape matters more than the visual, the exact steps using Microsoft's own documented approach, and the limitations worth knowing before you promise a stakeholder a live chart.

How Do You Create a Burndown Chart in Power BI?

You build it from a table of daily historical snapshots, not from your current work item list, and you render it with an ordinary column or line chart using a date field on the horizontal axis.

If your work lives in Azure Boards, Microsoft documents the whole thing. You connect Power BI to the Analytics OData endpoint, query the WorkItemSnapshot entity set, and group the result by date. That entity set exists specifically because it holds a row per work item per day, which is exactly what a trend chart needs.

The sample report Microsoft publishes uses a stacked column chart with DateValue on the x-axis, Count on the y-axis, and State as the legend. That is the entire visual configuration. All of the real work happens in the query that produces the snapshot table.

Not sure whether your reporting problem is the chart or the data behind it? Get a free audit and we will tell you which one to fix first.

If your work lives somewhere else, the principle is unchanged. You need one row per day per item, or at minimum a daily total of remaining work, and then the chart is trivial.

Why a Burndown Is Harder Than It Looks in Power BI

The visual is the easy half. Three things trip people up, and all three are about the data rather than the chart.

A burndown needs history, and most tables only hold the present

When you connect Power BI to a project tool and pull the work items, you get the current state of each one. A story that was open on Monday and closed on Thursday appears once, closed. There is no record that it was open on Monday, so there is nothing to burn down.

This is why the first attempt so often produces a chart with one bar on it. The data is a photograph, and a burndown needs the film. You either query a source that already stores daily snapshots, or you build your own by appending a dated copy of the table on a schedule.

Power BI ships no burndown visual

Scroll the visualizations pane and you will find column, line, area, stacked, combo and scatter charts. There is no burndown. That is not an oversight. A burndown is a column or line chart with a particular field arrangement, in the same way that a sprint report is a table with particular filters.

Marketplace visuals exist, and some are genuinely good, but they do nothing you cannot do with a built-in chart once the snapshot table is right. Reaching for a custom visual to solve a data problem is the most common wrong turn here.

The ideal line is a calculation, not a field

A proper burndown has two lines: actual remaining work, and the ideal straight line from the starting scope down to zero on the last day. Your source data contains the first. It almost never contains the second.

Microsoft's sample report does not include an ideal line at all, which is worth knowing before you promise one. If you want it, you create it yourself with a measure that takes the scope at the sprint start and subtracts an even slice for each elapsed day. That needs a proper date table in the model, and it needs the sprint start and end dates available as values rather than as filter context.

A dashboard nobody trusts is worse than no dashboard. Request a free audit and we will pressure-test the numbers behind yours.

How Do You Build It, Step by Step?

These steps follow the Azure Boards route, because it is the one Microsoft documents end to end. The last step covers what changes if your data comes from elsewhere.

Step 1 — Confirm you have access

You need to be a member of the project with at least Basic access. Analytics queries are open to project members by default, so in most organisations there is nothing to request before you start.

If the connection fails with a permissions error rather than a bad-URL error, that is the thing to check first. Analytics respects the same permissions as the rest of Azure DevOps, including area path security, so a report can succeed for you and return fewer rows for a colleague.

Step 2 — Connect with an OData feed

In Power BI Desktop, use Get Data, then OData Feed, and paste the endpoint with your query appended. The base URL takes the form https://analytics.dev.azure.com/{organization}/{project}/_odata/v3.0-preview/WorkItemSnapshot, replacing the two placeholders with your own values and dropping the braces.

There are three documented ways into Analytics: a prebuilt Analytics view, an OData query, and the OData feed. Views are the easiest and are tuned for status and trend reporting, but a custom burndown usually needs a shape no view provides, which is why the documented sample uses a query.

Step 3 — Append the query that shapes the data

This is the part that matters, and it is where a burndown is won or lost. The documented sprint query filters to the current iteration and groups by date:

$apply=filter(
  WorkItemType eq 'User Story'
  and startswith(Area/AreaPath,'{areapath}')
  and StateCategory ne 'Completed'
  and DateValue ge Iteration/StartDate
  and DateValue le Iteration/EndDate
  and Iteration/StartDate le now()
  and Iteration/EndDate ge now()
)
/groupby(
  (DateValue,State,WorkItemType,Priority,Area/AreaPath,Iteration/IterationPath),
  aggregate($count as Count, StoryPoints with sum as TotalStoryPoints)
)

Read it from the inside out. The filter narrows to user stories in one area path that were not yet complete, bounded to the dates of the sprint that is running now. The groupby then collapses the snapshot rows to one row per date per state, counting the stories and summing their points.

Step 4 — Decide what you are burning down

The query above aggregates both $count and StoryPoints, so you can chart either story count or total points without changing anything. If you track tasks in hours instead, filter WorkItemType eq 'Task' and aggregate RemainingWork as your measure, and add Activity to the grouping if you want to split the chart by type of work.

Pick one and label the axis with it. A burndown that silently mixes counts and points is the most common way these charts lose the room's trust.

Step 5 — Expand the record columns

Power Query will show Area, Iteration and AssignedTo as record objects rather than values. Expand each one so the underlying fields become real columns, rename the query from the default Query1, then choose Close & Apply.

Step 6 — Drop in the chart

Add a stacked column chart. Put DateValue on the x-axis, your measure on the y-axis, and State on the legend. That is the whole visual configuration in the documented sample.

One detail catches almost everyone: select DateValue itself, not the date hierarchy Power BI offers. The hierarchy rolls your daily snapshots up into months, which flattens a two-week sprint into a single column and looks like the query failed.

Step 7 — Scope it to your team

The area path filter works well for a single team's board. If your teams do not map cleanly to area paths, swap that clause for a team filter instead, which matches on the team name rather than the path prefix.

Step 8 — If your data is not in Azure Boards

The only step that really changes is the first. Pull your items from Jira, a service desk, or a spreadsheet, and either use a source that keeps dated snapshots or schedule a dataflow that appends today's open items with today's date.

Once you have a table with a date column and a remaining-work column, steps six onward are identical. The chart does not care where the history came from, only that it exists.

Reporting on work that search traffic is supposed to drive? Start with a free audit so the inputs are worth charting.

When Is a Burndown the Right Chart?

A burndown earns its place when there is a fixed scope and a fixed deadline, and the only interesting question is whether the two will meet. That is exactly a sprint, and it is why the chart grew up inside Scrum.

It is the wrong chart for a few common situations. If scope keeps changing, a burndown hides the churn: work added mid-sprint makes the line go up, which reads as a mistake rather than as the scope change it actually is. A burnup chart, which plots completed work rising against a separate scope line, shows both movements honestly and is the better choice for anything longer than a sprint.

If your question is about flow rather than finishing, a cumulative flow diagram answers it better by showing how much work is sitting in each state over time. And if you want to know how much a team reliably delivers per sprint, that is a velocity chart, not a burndown.

One more case deserves naming. If the deadline is fixed but the scope is explicitly negotiable, neither chart is really the point and a simple list of what has been dropped will tell the story better than any line.

Pick the chart by the question. A burndown answers "will we finish", and nothing else.

What Are the Limitations Worth Planning For?

Several of these are documented and still catch teams out.

Analytics is not real time. The data is a copy, and a change can take up to thirty seconds to appear. That is fine for a daily chart and misleading if someone expects the board and the report to match to the second during a stand-up.

Large results are paged. Responses above ten thousand rows come back in pages, and snapshot data grows quickly because it stores a row per item per day. A year of history on a busy board is a lot of rows. Keep the date filter tight and aggregate on the server side, which is exactly what the groupby in the query is doing.

Reconfiguring paths destroys history, permanently. This is the serious one. Deleting area path values or reconfiguring iteration paths affects burndown and burnup charts, sprint burndowns, velocity for any team whose area path changed, and any historical trend that references those paths. The data cannot be recovered afterwards. Agree a path structure before you build reports on it.

The current-sprint query shows only the current sprint. The documented query is deliberately bounded to the iteration that is running now, which is usually what you want on a team dashboard and useless for a retrospective. The all-sprints variant drops those bounds but pins a hardcoded start date, so change it to something sensible for your project rather than inheriting a date from a sample.

Unestimated items vanish from a points burndown. If you chart story points and half the backlog has no points on it, those stories contribute zero and the chart understates the remaining work. Chart story count alongside points, or make estimation a condition of entering the sprint.

Closed-state mapping matters. The filter excludes items whose state category is complete, not items in a state literally named "Done". If your project has custom states, check how each one maps to a state category before trusting the result.

The documentation is not perfectly self-consistent. Microsoft's own sample describes a stacked column chart in the text while the accompanying image is labelled as a clustered column chart. Either renders a usable burndown, so it is not a problem to solve, but it is a reminder to read the field mapping rather than copy a screenshot.

Power BI vs the Chart Already in Your Project Tool

Azure Boards ships burndown, burnup, velocity and cumulative flow widgets that need no query, no model and no maintenance. Jira and most other trackers do the same. If a team only wants to see its own sprint, the built-in widget is the right answer and building the Power BI version is work for no gain.

Power BI wins in three situations. The first is combining sources: a programme view across several tools, or work data joined to finance or support data that the tracker cannot see. The second is history the tool will not keep, where you want trends further back or at a grain the widget does not offer. The third is distribution, where the chart has to live in a report alongside everything else an executive looks at, in your own layout and branding.

If none of those apply, use the widget. If one of them does, the snapshot query above is the foundation, and a burndown is one visual on what will probably become a broader report.

There is a middle path worth considering. Keep the built-in widget for the team's daily use and build the Power BI version only for the audience that needs the wider context. Two charts of the same thing is not duplication if they serve two audiences, and it saves you maintaining a model nobody at stand-up ever opens.

Want a second pair of eyes on what you are measuring and why? Take the free audit.

Final Thoughts

The chart is not the hard part. A burndown in Power BI is a column chart with a date on one axis, and you could build it in a minute if the data were already in the right shape. Everything that makes this task feel difficult comes down to one requirement: you need a row per day, and most tables only tell you about today.

So solve that first. Query a snapshot entity if your tool offers one, and append dated copies on a schedule if it does not. Then add the ideal line yourself, because your source will not supply it, and be honest with the people reading the chart about what a rising line means when scope has changed.

If the burndown is heading for a wider report rather than living alone, our guide to building a project management dashboard in Power BI covers which visuals actually earn their place and which ones are decoration.

Build it on one team's current sprint, show it at the next stand-up, and let the questions people ask tell you what to add.