Introduction
If every Sprint Review ends with a familiar phrase—“we’ll carry this over”—you’re stuck in the cycle of unfinished sprints. It drains morale, muddies forecasts, and delays value. The good news: this isn’t a motivation problem; it’s a flow problem.
In this guide, you’ll learn how to diagnose carryover using three practical flow metrics—throughput, WIP, and aging WIP—and then fix it with capacity-aware Sprint Planning. We’ll wrap with a short case study showing a concrete lead time reduction after these changes.
Why Carryover Happens (and How Flow Reveals It)
Carryover is a symptom of invisible queues and unbalanced flow. Typical causes include:
- Overstuffed Sprint Backlogs relative to actual availability.
- High WIP that scatters focus and slows everything.
- Aging items hidden in the middle of the board, quietly stuck.
- Dependency bottlenecks (QA/UX/DevOps specialized steps) that starve or flood downstream stages.
Kanban practices explicitly call out flow metrics to surface these issues: WIP (items started, not finished), Throughput (items finished per time), Work Item Age (time since start for in-progress items), and Cycle Time. When Scrum teams adopt Kanban’s flow lens, they also get a clear reminder of Little’s Law—if WIP is high for a given throughput, cycle time (and lead time) will be long—so limit WIP first. scrumorg-website-prod.s3.amazonaws.com
Bottom line: Measure flow, then tune WIP and policies. You can’t plan your way out of carryover if the system is chronically overloaded.
Flow Metrics 101 (Throughput, WIP, Aging WIP)
Throughput
Count how many items you finish per Sprint (or per week). This is your historical delivery rate. In the Kanban Guide for Scrum Teams, throughput is one of the four basic flow metrics to track. scrumorg-website-prod.s3.amazonaws.com
WIP (Work in Progress)
This is how many items are started but not finished. High WIP spreads attention thin, creates context-switching costs, and increases coordination overhead. Limiting WIP turns your system into a pull system—start new work only when there’s capacity—and is a foundational practice for flow. scrumorg-website-prod.s3.amazonaws.com
Aging WIP (Work Item Age)
Unlike cycle time (which you only know when an item finishes), age tells you how long an in-progress item has been alive right now. Aging is a powerful early-warning signal: if an item’s age approaches or exceeds your typical cycle time, it’s likely blocked or starved and needs attention today. ProKanban
Why these three?
Because they’re diagnostic and actionable. If carryover is chronic, you’ll typically see too much WIP, flat throughput, and aging items clustering in certain workflow states. The Kanban Guide explicitly connects these metrics to Little’s Law and recommends lowering WIP first when cycle times are too long. scrumorg-website-prod.s3.amazonaws.com
Make Aging Visible (So You Can Save Work Before It Slips)
Add age badges to every in-progress card (most ALM tools allow this), and guide the Daily Scrum around flow:
- What’s oldest right now?
- Which items are close to (or over) our service level expectation (SLE) for cycle time?
- What’s blocked and who can swarm it?
The Kanban Guide recommends a flow-based Daily Scrum that focuses on where flow is lacking, including calling out Work Item Age and items breaching the SLE. scrumorg-website-prod.s3.amazonaws.com
Tip: Sort columns by oldest first. Make “finish the oldest” the default pull policy unless there’s a clear reason not to.
Capacity-Aware Sprint Planning (Not “Wishful” Planning)
Classic over-commitment mistake: planning by last sprint’s velocity while ignoring holidays, PTO, support duty, or a big migration in the pipeline. A better approach:
- Start with historical flow: what’s our throughput (e.g., average items finished per sprint) and average cycle time?
- Adjust for next sprint’s capacity: subtract time off, training, on-call, big meetings.
- Apply WIP policies: set a per-stage WIP limit that forces finishing before starting.
- Choose items to match capacity: avoid stuffing the Sprint Backlog beyond what WIP limits allow.
- Draft a Sprint Goal that fits the available capacity and the system’s flow (not just point totals).
If you want a deeper dive on the velocity-vs-capacity trade-off (including a hybrid formula), see my article Velocity vs Capacity: Best Metric for Sprint Planning. It explains when to temper historical numbers with real availability so you stop over-committing and actually finish. (Internal link)
The Policy Layer: Definition of Workflow + WIP Limits
To make flow durable, codify how work moves:
- Definition of Workflow (DoW): states, entry/exit policies, and pull rules.
- WIP limits per active state (and sometimes per person/skill if necessary).
- An SLE (e.g., “85% of items finish in ≤ 8 days”) to guide aging alerts and escalation.
The Kanban Guide for Scrum Teams describes these practices, including explicit WIP limits, active management of items in progress, and using flow metrics in every Scrum event (Sprint Planning, Daily Scrum, Review, Retro). scrumorg-website-prod.s3.amazonaws.com
Before/After: Cutting Lead Time by 45% in 6 Sprints
Context
A 10-person product team shipping a B2B web app struggled with unfinished sprints. On average, 35% of items spilled into the next sprint. Lead time (idea to production) hovered around 18 days.
Interventions (Week 0 → Week 1)
- Set WIP limits at 2× the number of active developers per key column (e.g., Dev: 6, Code Review: 4, Test: 3).
- Switched Daily Scrum to a flow-first agenda: oldest first, unblock aging work, pull only when WIP < limit.
- Adopted capacity-aware planning (holidays, on-call, PTO subtracted upfront).
- Introduced an SLE: “85% of items finish in ≤ 8 days” and added age badges.
Results (After 6 sprints)
- Carryover dropped from ~35% to <10%.
- Lead time decreased from 18 days → 10 days (≈ 45% reduction).
- Throughput rose from 12 to 16 items per sprint (with fewer context switches).
- Predictability improved: 80–90% of items now finished within the SLE window.
Why it worked
Limiting WIP and actively managing aging WIP unlocked flow and made capacity real. This aligns with industry research: DORA’s “four keys” (including lead time for changes) predict better organizational outcomes; elite performers achieve very short change lead times (e.g., < 1 day in 2023 benchmarks). Doradevlake.apache.org
Tools & Rituals That Keep Carryover Gone
- Aging WIP dashboard (tile on your team TV or wiki home).
- Blocked-item SLA (e.g., must escalate within 24 hours).
- Pull policies written on the board (“finish oldest first”).
- Retros that start with a cumulative flow diagram and aging table, not opinions.
- Training on flow basics for the whole team (not just the Scrum Master).
For a structured, metrics-driven approach to decisions, explore our Evidence-Based Management program and Kanban program.
FAQ
Q1: Should we use velocity or capacity for Sprint Planning?
Use both. Start with historical throughput/velocity, then scale by next sprint’s capacity (absences, support duty). This hybrid avoids over-commitment and reduces unfinished sprints. For details, see Velocity vs Capacity.
Q2: What’s a good starting WIP limit?
Begin roughly at 1–2 items per person per active state, then tune based on aging and blocked trends. The Kanban Guide stresses that explicit WIP limits create a pull system and improve flow and focus. scrumorg-website-prod.s3.amazonaws.com
Q3: How do we know if work is “aging badly”?
Compare Work Item Age to your SLE. If an item’s age is near/over the SLE boundary (say the 85th percentile), swarm it. The Kanban Guide recommends tracking Work Item Age and using it in Daily Scrum to maintain flow. scrumorg-website-prod.s3.amazonaws.com
Q4: Is lead time the same as cycle time?
Related, but not always. Cycle time often measures start→finish within the team’s workflow; lead time may include time before “start” (e.g., waiting in backlog) and after “finish” (e.g., deployment steps). DORA highlights lead time for changes as a key capability tied to performance. Dora
Conclusion & Next Step
To stop unfinished sprints, measure flow, limit WIP, and plan to actual capacity, not hopes. Track throughput, WIP, and aging WIP daily; let them shape Sprint Planning and your improvement experiments. Do that, and your unfinished sprints become finished increments, faster lead times, and happier stakeholders.
If you want a hand turning these ideas into outcomes, book a session and we’ll set up a flow-based plan tailored to your context. (Internal link)
