Sprint review, Friday afternoon. The board says forty-one points planned, thirty-four done. Two stories roll into next sprint — one waiting on an API contract from the platform team, one that turned out to be bigger than it looked on planning day. Nobody flinches. Carryover happens; the team has seen it a hundred times, and so have you.
Six sprints later, the release everyone committed to in January is three weeks adrift, and nobody can point to the sprint where it happened. That is the uncomfortable thing about sprint spillover: no single instance of it feels like a problem, because no single instance of it is.
Sprint spillover is normal. Invisible spillover isn’t.
Sprint spillover — carryover, rollover, unfinished work at the end of the sprint — is what happens when knowledge work refuses to fit neatly into two-week boxes. It never fits neatly. A team that closes every item every sprint is probably under-planning, not over-performing. Treated honestly, a little spillover is just the texture of real delivery.
The trouble starts with how most release plans metabolize it — which is to say, they don’t. Each sprint opens as a fresh start: yesterday’s unfinished story is re-planned, the burndown resets, and the release-level picture quietly absorbs the drift with nobody assigned to notice. Carry over four points a sprint against a forty-point cadence and you are delivering roughly ten percent less than the plan assumes — compounding, sprint after sprint, underneath a release date that has not moved.
The confidence vote was right. The plan stopped listening.
Here is what sprint carryover is not: proof that your team can’t plan. When the team held up fists at PI planning and committed to the March release, that vote was expert engineering judgment — people who know this codebase, this domain, and their own delivery rhythm, voting on evidence they validated together in the room. A team’s real throughput already includes its real spillover. The vote was not wrong on the day it was cast.
What erodes a committed date is what happens after the vote — and spillover is where that erosion first becomes visible. Look inside any sprint’s carryover and you will usually find the three things that erode a committed release date in miniature: the small mid-sprint ask that pushed a planned story out (scope creep), the item stuck waiting on another team’s API (a dependency surfaced too late), and the week the team ran a person short while unplanned work ate the difference (a capacity change). Spillover is post-commitment erosion at sprint grain — the early-warning signal, visible weeks before it shows up as a slipped quarter.
Price carryover into the forecast — don’t pad it away
Teams usually reach for one of two responses, and both make things worse. Moralizing spillover — treating carryover as a failure to be explained in the retro — teaches people to plan smaller and hide the variance. Padding for it buries a private buffer inside estimates, where no one can see it, challenge it, or renegotiate it.
The better move is to let your delivery data carry the information it already contains. Advanced Release Planning forecasts your release from throughput windows — samples of what each team actually completed, sprint over sprint, across the window you choose. If your team historically carries a story or two, that reality is already priced into the thousands of Monte Carlo simulations behind the forecast date. You own the assumptions — which throughput window to trust, whose capacity counts, what is in scope. The app does the arithmetic at a scale no spreadsheet can, and keeps doing it as every sprint closes.
Watch days, not story counts
Because the forecast re-runs as work completes, spillover stops being an anecdote and becomes a number: the forecast drifting against your committed date, in days, with a 50/85/95% confidence band around it. Two stories rolled once? The date may not move at all. A pattern of them, stacked on a dependency that has not cleared? The 85% date slides nine days right — and you see it on Tuesday morning, not in the retrospective after the miss.
That is the moment to renegotiate, while options are still open: trim scope at the cut-line and watch the band tighten, re-sequence the dependency, or reset the commitment with leadership before it becomes a surprise. Just be wary of the instinctive rescue — Brooks’s Law has firm opinions about adding people to a late release. The teams that hold their dates are not the ones with zero carryover; they are the ones who renegotiate before the slip instead of explaining after it.
Make spillover visible before it becomes a slip
Your team already knows its own rhythm — the confidence vote proved that. Give your release plan the same knowledge. Try Advanced Release Planning for Jira, run a live forecast against your committed date, and see what your carryover has been trying to tell you. For the mechanics of how the forecast chooses its data, see throughput windows in the docs.
Leave a Reply
Your email is safe with us.