Sprint Analytics · November 5, 2026 · 5 min read · By Henry Sword

What to Show in a Sprint Review Using Azure DevOps Data

Demo the increment first, then four numbers that support the conversation: delivered vs committed, scope change and carryover, a burnup, and a next-sprint range.

  • #sprint review
  • #sprint reporting
  • #burnup chart
  • #carryover
  • #commitment reliability
  • #azure devops

Show the working increment first, then a few numbers that support the conversation: delivered against committed, how scope changed, a burnup of the sprint, and a range for the next one. If your burndown stays flat until the last day, work is usually reaching Done in a batch at the end, and a burnup that separates scope from completed work tells that story more honestly.

Start with the increment, not the charts

A sprint review is a working session about the product. Stakeholders should see what was built, try it where they can, and give feedback that shapes the backlog. Numbers are there to answer the questions that come up: did we get what we planned, why did that slip, and what can we expect next? Keep the data part short and put it after the demo.

Delivered vs committed

The first question most stakeholders ask is how much of the plan landed. In Agile Analytics, Sprint Summary gives each team a sprint baseline with commitment reliability, scope churn, carryover, planned work and bugs. The card headline says how much committed work was "not delivered". That wording is deliberate: work that was not delivered is not always carried over, and the two numbers answer different questions. Reviewing several teams together? With two or more teams selected, Sprint Summary shows a Teams at a glance table above the cards, with delivered of committed, done of all items, scope change and carryover for each team. More on building the report is in sprint reporting in Azure DevOps without Power BI.

Scope change and carryover

Commitment reliability means little without the scope picture beside it. Agile Analytics counts carryover with one rule. For a finished sprint, an item is carryover when it:

  • was in the sprint at the end of at least one sprint day,
  • was not done when the sprint ended or when it left (done means the first state mapped as Done in Workflow Mapping, with one day of grace after the last sprint day), and
  • stayed in the sprint to the end or moved straight into the next sprint.

Two cases worth explaining in the room

An item moved back to the backlog unfinished is removed scope, not carryover, so it shows up in scope change. An item pulled in by mistake and taken out the same day never counts. Late additions do count, and the view discloses them ("N added in the last 2 days"), so nobody is surprised by a number that rose in the final hours. The percentage divides carryover by every item that was in the sprint at the end of at least one day, so it does not need a commitment, and a running sprint shows a dash. The full rule is in the carryover docs.

Why your burndown stays flat until the last day

A burndown drops only when work finishes. If stories are large, if testing happens at the end, or if items wait in review until the last day, the line stays flat and then falls off a cliff. Added scope makes it worse, because new work pushes the line up and hides the progress that did happen. A burnup separates the two effects. The Agile Analytics Dashboard has a card titled Sprint Burndown, hidden by default (enable it under Customize), whose chart heading is Sprint Burnup. It covers the current or latest sprint with Scope, Ideal and Completed lines, and a toggle switches between Items and Story Points. In a review you can point at the day scope grew and show that completed work still moved. If Completed stays flat until the end, take that to the retrospective as a question about item size and flow. More in the Azure DevOps burnup chart.

The next-sprint forecast

Close the data part with a range, not a promise. Next Sprint Planning combines team capacity, a Monte Carlo forecast on the last 6 sprints, cycle time per bucket and historical commitment reliability into a recommendation, and it can forecast before capacity is set. For a quick tile on an Azure DevOps dashboard, the Sprint Forecast widget is free for every organisation, with no licence needed. See next sprint planning in Azure DevOps for how to read the recommendation.

Sharing the numbers

Some people will miss the review. A few ways to share what you showed:

  • PNG, CSV and Markdown exports for charts and tables you want in meeting notes or a wiki.
  • Retro Snapshot for a retro-ready summary you can copy or export in one click. Its Carryover row still counts committed work that was not delivered, so quote carryover from Sprint Summary.
  • Exec Report for leadership: a one-page summary with forecast, risks, delivery trend and DORA, shared as a PDF, a copied summary or copied email text. It is built in your browser.

Try it

Agile Analytics runs on Azure DevOps Services (cloud). The 30-day free trial starts on install with no credit card, and everyone in the organisation has full access while it runs. The sprint reporting page shows the views, and the extension is on the Azure DevOps Marketplace.

Related: Azure DevOps sprint reporting · What belongs on a sprint health dashboard

Compare your Azure DevOps reporting options before you commit

See how built-in ADO reporting, Power BI, and Marketplace extensions stack up, then start the 30-day trial to evaluate the extension path inside your own organisation.

Related reading

Find our articles faster: add Agile Analytics as a preferred source in Google Search.Add preferred source →