Carryover work

Most squads underestimate how much carryover work they accumulate until a sprint review makes it impossible to ignore. Carryover work refers to any planned work that was not completed within the sprint or iteration it was originally scheduled for and gets rolled into the next cycle. When it happens occasionally, it is a planning footnote. When it happens every sprint, it signals a systemic problem in your delivery process. This page covers the definition, how to measure it, what benchmarks look like, how to reduce it, and how DevStats surfaces it across your squads.

Key takeaways

• Carryover work is any planned sprint item that does not reach a done state by the end of the sprint it was committed to. It matters because repeated carryover erodes forecast reliability, frustrates stakeholders, and masks the real capacity and flow of your engineering squads.
• Carryover rate is calculated as the number of incomplete sprint items divided by total sprint commitments, expressed as a percentage. A carryover rate consistently above 20% is a signal worth investigating, though benchmarks vary by team size, sprint length, and how strictly done is defined.
• The most common mistake teams make is treating carryover as a normal cost of doing business and never examining the root cause. Carryover is a symptom, not a problem in itself. The underlying cause could be scope creep, underestimated complexity, blocked dependencies, or a review bottleneck in the code review process.
• DevStats tracks sprint-level carryover automatically by connecting to your issue tracker, with benchmarks against 1,000+ engineering teams. You can see your carryover rate broken down by squad and sprint in the sprints feature. Start a free trial to see your numbers in under two minutes.

Carryover work definition

Carryover work is any sprint commitment that is not completed by the end of the sprint in which it was planned, and is moved to a subsequent sprint or backlog. It is a direct measure of how accurately a squad executes against its own plan within a fixed time window.

Technically, carryover rate is calculated as: Carryover Rate = (Incomplete sprint items / Total sprint commitments) × 100. Data sources include your issue tracker (Jira, Linear, GitHub Issues) and sprint board configuration. When carryover accumulates across sprints, it compounds into a reliability gap that erodes confidence with product and business stakeholders, making it harder to commit to roadmap dates with any credibility. Teams that use planning accuracy data alongside carryover rate get a clearer picture of where their estimation process is breaking down.

Why carryover work matters for engineering teams

When squads do not track carryover work, the consequences are invisible until they compound. Stakeholders see missed sprint goals as a reliability problem. Engineering managers see it as a velocity problem. Players on the squad often experience it as a context-switching problem, carrying half-finished work across sprint boundaries while absorbing new commitments on top. None of these perspectives is wrong, but none of them on its own points to the fix.

Carryover directly affects your ability to forecast delivery dates, hit quarterly roadmap targets, and maintain a sustainable pace for your squad. High carryover rates are also a leading indicator of burnout: players accumulate a growing pile of in-flight work that never fully closes. In the SPACE framework, carryover touches satisfaction, performance, and efficiency simultaneously, making it one of the more revealing process signals available to an engineering leader. Reviewing your throughput data alongside carryover rate gives you a sharper read on whether your squad is completing less work or just committing to more than it can absorb.

Measurement is the starting point, not the answer. Once you know your carryover rate and where it originates, you are in a position to decide what to change.

How to measure carryover work

To calculate carryover rate, count all issues, stories, or tasks that were added to a sprint and not marked done by sprint close, then divide by total sprint commitments. Multiply by 100 to express it as a percentage. Your issue tracker is the primary data source. For this to be meaningful, your squad needs a consistent definition of done and a discipline around not retroactively adjusting sprint scope after the fact.

No single published benchmark exists for carryover rate in the way DORA benchmarks exist for deployment frequency. What follows is a qualitative framework based on observed patterns across engineering teams, and benchmarks will vary by team size, sprint length, and codebase complexity. You can compare your squad's carryover rate against peers using DevStats benchmarks.

Note: these ranges are qualitative guides, not published standards. Teams with shorter sprint cycles or high-uncertainty work may see naturally higher carryover. Context always matters when interpreting the number.

Carryover work in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed that her squads were consistently reporting 30–40% carryover across three consecutive sprints. The sprint reviews looked fine on the surface: teams were busy, PRs were merging, and no one was raising blockers in standups. When she pulled the data, she found that a disproportionate share of carryover items were stories that had entered code review in the final two days of the sprint and never cleared before sprint close. The bottleneck was not capacity. It was review latency.

She set a squad norm: any story in review by day eight of a ten-day sprint gets prioritized by the next available reviewer before new work is picked up. She tracked PR cycle time and carryover rate together over the following month. Carryover dropped from 35% to 14%, and the squad's sprint predictability improved enough that the product team started trusting the sprint forecast again. The data surfaced the pattern. She made the call.

How to reduce carryover work

1. Cap sprint commitments to 80% of historical capacity. Most squads overcommit because they plan to average velocity, not accounting for interruptions, reviews, and meetings. Use your last six sprints of throughput data to set a realistic ceiling. Watch for immediate pushback from stakeholders who want more committed per sprint: that conversation is worth having explicitly.
2. Break stories down until no single item exceeds two days of work. Large stories are the most common source of carryover. If a story cannot be completed in two days, it is almost certainly underspecified or too broad. Smaller items also make blockers visible faster, so you can act before sprint end.
3. Treat review latency as a first-class sprint health signal. If items are completing development but stalling in review, your carryover rate reflects a process gap, not a capacity gap. Monitor issue cycle time by stage to identify where items are sitting. Set a squad agreement on maximum review wait time.
4. Run a mid-sprint check on in-flight items. By day five of a ten-day sprint, any item not yet in active development is at risk of carrying over. A five-minute mid-sprint triage, not a full meeting, gives the engineering manager a chance to descope or reassign before it becomes a sprint failure.
5. Audit your definition of done. Carryover sometimes spikes when the criteria for closing a story shift mid-sprint. Agree on done criteria at sprint planning and do not change them during the sprint. Inconsistent definitions inflate carryover numbers and make trend data unreliable.

Carryover work vs. sprint spillover

Carryover work and sprint spillover are often used interchangeably, but they describe slightly different things. Carryover refers to items that were planned in a sprint and not completed, while spillover sometimes specifically describes work that was in progress at sprint end and actively continues into the next sprint, as opposed to work that was simply not started.

Use carryover rate when you want to evaluate your squad's sprint commitment reliability. Use spillover tracking when you want to understand WIP continuity and flow across sprint boundaries. Both signals together give you a fuller picture of sprint health, which you can review alongside your sprints data in DevStats.