Azure DevOps keeps the history you need, but the built-in screens make you rebuild scope change by hand. The Sprint Summary view in the Agile Analytics extension compares the sprint with what it held at the end of day 1, and lists every item added after that, grouped by the day it arrived, plus the items removed.
Why the sprint backlog alone cannot show it
The sprint backlog answers one question: what is in this iteration right now. That leaves three blind spots.
- Added items look like they were always there. A story pulled in on day 6 sits next to the stories the team planned, with nothing marking it as late.
- Removed items disappear. Once someone moves an item out, it no longer appears in the sprint backlog at all.
- Net change hides churn. If three items came in and three went out, the count is unchanged, but the plan clearly is not.
Doing it by hand
Azure DevOps records every Iteration Path change in each work item's history, so the information exists. Without an extension, the work usually looks like this.
- Note or export the sprint contents at a fixed point, such as the end of day 1.
- Run a work item query to get the sprint as it is today.
- Open each item's History tab and check when its Iteration Path was set to this sprint.
- Find removed items with a separate query, then check each one the same way.
- Put the moves in a spreadsheet, by date.
What the burndown tells you
The built-in burndown can show the total scope line moving. That tells you scope changed, but not which items moved or when each one arrived.
Related: How to read a burndown honestly
Step by step in Sprint Summary
Sprint Summary is in the Health group of the Agile Analytics hub, under Boards in your project.
- Open Sprint Summary, then pick the team and the sprint.
- Read Planned Items, "Committed at end of day 1". That is everything in the sprint at the end of its first day, measured in UTC.
- Read Scope Change. The + number is how many items were added after day 1, and the - number is how many were removed.
- Open the list of added items under the tiles. Items are grouped by the day they arrived, with the sprint day and a link to each one. It always matches the + number on Scope Change.
- Open the list of removed items, which shows when each one left.
If nothing was planned by the end of day 1
Sprint Summary says so, tells you how many items arrived later and when the first one came, and opens the list by itself. A team that plans the day before the sprint starts is covered, because those stories are already in the sprint when day 1 ends.
Using it in a retro without blaming anyone
Scope change is rarely one person's doing. It comes from production bugs, stakeholder requests, discovered work and planning gaps. Sprint Summary shows what arrived and when, not who moved it, so the conversation starts from the work.
- Start with the shape. Five items on day 2 suggests a planning gap. One or two every day suggests a steady stream of interrupts. Several in the last days suggests late requests.
- Sort the items into a few kinds: urgent bug, outside request, work discovered while building, or an item that should have been planned.
- Ask what made each kind arrive. "What would have let us see this at planning?" gets better answers than "Why was this added?"
- Look at what left too. Items dropped to make room are part of the same story.
- Agree on one change, such as a buffer for known interrupts, then compare the next sprint.
Keep it a signal, not a target
A team pressured to show zero scope change will simply stop adding urgent work to the sprint, and you lose the visibility. Note that an unfinished item moved back to the backlog is removed scope, not carryover.
Related: How carryover is counted
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.
Related: Sprint reports: scope and carryover · Install instructions