Sprint carryover is work the team committed to that did not finish inside the sprint and rolls into the next one. A little carryover is normal. A story that missed by a day is not a crisis. Carryover that shows up every sprint is different. It usually points to oversized work, unstable scope, hidden dependencies or weak daily habits, and it quietly erodes the trust stakeholders put in a sprint plan.
Why carryover hurts predictability
Teams can look busy while delivery confidence declines. Carryover causes several problems further down the line:
- Velocity is harder to read, because the same work is half-counted in more than one sprint.
- Burndown charts flatten late in the sprint and then reset with unfinished scope.
- The next sprint starts partly full, so there is less room for the work that was planned for it.
- Stakeholders stop trusting commitments, even when the team is working hard.
- Retrospectives turn into opinion, because nobody has a clean record of what actually finished.
Define carryover before you measure it
Two numbers often get called carryover, and they answer different questions. The first is items moved to the next sprint: anything whose iteration was changed to the following sprint. It is easy to count, and it is also easy to game, because an item moved back to the backlog instead of the next sprint simply disappears from it. The second is committed work not delivered: every item that was in the sprint when the commitment was set and did not reach Done by the end. That one does not care where the unfinished item went. If you want a number that cannot be improved by tidying the board, use the second.
- Fix the moment the commitment is taken. If the baseline moves every time an item is added, the sprint always looks on track.
- Count items, not story points, unless your team sizes consistently. A missed 8-point story and a missed 1-point story are both a broken promise to someone.
- Leave out cancelled work. An item that was deliberately removed from the plan is a scope decision, not a delivery miss.
Seeing carryover in Azure DevOps
Azure DevOps stores only an item’s current iteration, so a backlog view tells you where unfinished work is now, not what the sprint looked like when it started. The built-in Velocity widget is the closest standard view: for each iteration it shows planned work next to completed, completed late and incomplete work, which is a reasonable first look at whether a team finishes what it plans. For the rest you need the item history, which records each time the iteration path changed.
The usual root causes
Most teams with recurring carryover have one or more of these patterns. They tend to show up in the data before anyone names them.
- Stories are too large to finish inside one sprint. Look for items that sat in progress for most of the sprint.
- Work enters the sprint before it is ready: the design, a dependency or an environment is not in place yet.
- New work is added mid-sprint without anything else being taken out.
- Testing and review happen at the end, so several stories reach the last day together and some do not make it.
- The team starts too many items at once, so everything moves slowly and several items miss together.
Reducing carryover without lowering the bar
The aim is not to commit to less forever. It is to commit honestly and finish consistently.
- Slice work so a story can go from start to done in a few days, not most of the sprint.
- Make readiness explicit before planning: dependencies, environments and acceptance criteria agreed before an item enters the sprint.
- When something is added mid-sprint, agree what comes out. Track scope added against scope completed so the trade is visible.
- Limit work in progress. Finishing two items is better than having five in progress on the last day.
- Use the standup to talk about the oldest in-progress items first, while there is still time to split or swarm.
- Plan the next sprint with the carryover in mind. If three items are coming back, they take capacity the team does not have for new work.
How to avoid gaming the number
Any metric that is watched gets managed. Carryover is easy to make look better without delivering anything more:
- Moving unfinished items back to the backlog on the last day, so they never count as moved to the next sprint.
- Committing to very little, so the team always hits the number.
- Closing items as Done and opening follow-up items for the remaining work.
- Adding items after the commitment and then counting them as part of it.
The defence is to look at carryover next to the numbers it trades against: commitment reliability, throughput and scope change. If carryover drops while throughput drops too, the team is committing to less, not finishing more. And talk about carryover as a planning signal for the whole team, never as a score for individuals.
What to look at in Agile Analytics
Agile Analytics uses the stricter definition for its carryover rate: items in the committed baseline that were not delivered by the end of the sprint, counted in items, with a 24-hour grace period after the sprint ends. The commitment is locked at the end of day 1 of the sprint. Items moved out of the sprint still count as committed, and items set to the Removed state count on neither side.
- Sprint Summary shows the per-team picture for one sprint. The Moved to next sprint tile counts items whose iteration was changed to the following sprint, and the list under it shows each item with a Carryover badge, the state it was in and when it moved. The Scope Change tile shows items added and removed after Day 1 as +N / -N.
- Delivery Signals has a Carryover Rate card with a trend across past sprints (six by default), marked Minimal carryover, Noticeable carryover or High carryover rate. Admins can change the threshold under Carryover rate (%).
- The Sprint Velocity card shows a Carryover column next to Commitment and Scope Churn for each of the last six sprints.
- The Retro Snapshot includes a Carryover row and, when more than 20% of the commitment carried over, an insight that says how many items carried into the next sprint.
Read those together. If carryover is high and scope change is high too, the plan changed under the team, and the conversation is with whoever added the work. If carryover is high and scope was stable, the team took on too much or the items were bigger than they looked. The in-product advice for that case is short: commit to less, or break items into smaller slices that finish within a sprint.
Related: What belongs on a sprint health dashboard · Velocity and burndown explained · Work item aging chart for standups · Azure DevOps sprint reporting
A good retrospective question
Instead of asking “why did we miss the sprint?”, ask “which stories should never have entered the sprint in their original shape?” Then pick one carried item and trace where it spent the most time waiting. Those two questions usually lead to better actions than debating whether the team should commit to fewer points next time.