The Sprint Ends. The Work Doesn't. Every Single Time.

TL;DR: If most sprints end with unfinished work rolling forward, you have a measurement problem that keeps getting resolved in favor of hope. Chronic carryover means planned capacity is bigger than real capacity, sprint after sprint, and everyone has stopped believing the plan. The cure costs one spreadsheet: measure your carryover rate over six sprints, find where the capacity actually went, and commit to what your measured throughput says fits. It works even if you never buy a tool.

Sprint review, 4pm. The demo goes fine. Then the quiet part: seven of the eighteen committed items slide to the next sprint. Nobody flinches. Someone says "we were a bit ambitious," the same way they said it last sprint, and the sprint before that, and the retro moves on, because carryover has stopped being information. It's just weather.

That's the tell. Not the unfinished work - the shrug. When rolling work forward is routine, your team has learned something your planning ritual refuses to learn: the commitment was never real. Everyone downstream of that commitment inherits a plan the people who made it don't believe: the roadmap, the stakeholders, the ship-date answer you owe your CEO.

Carryover is your throughput speaking. Planning keeps talking over it.

Strip the ceremony away and a sprint is a falsifiable claim: this much work, this many days. Chronic carryover means the claim gets falsified every two weeks and re-asserted anyway. The failure sits in the model, and the model belongs to planning, not to the team executing it. Three mechanisms do most of the damage:

Planned capacity assumes a fictional team. Planning fills the sprint as if every hour were feature hours. Real weeks don't work like that. In Stripe's Developer Coefficient survey of over a thousand developers, respondents self-reported spending 17.3 hours of a 41.1-hour week on maintenance (debugging, bad code, refactoring) before any new roadmap work. Whatever your org's real split is, if planning reserves nothing for it, the reserve gets taken anyway: out of the committed work, at the end of the sprint, where it's called carryover.

The sprint leaks intake. Mid-sprint "small asks," incident fallout, the unplanned-but-urgent: work enters after the commitment without anything leaving. Scope grows; the deadline doesn't; the overflow rolls. Its cousin is work that stalls rather than overflows, half the In Progress column quietly going dead, and both corrupt the same planning arithmetic.

The unit of commitment inflates. Story points are a team-local currency, and velocity is a metric that inflates under scrutiny: teams under pressure re-price the points rather than the promises. The SPACE research is blunt that no single metric captures productivity; a velocity chart that "recovered" while carryover stayed chronic is the canonical example of a number healing while the system doesn't.

Meanwhile the honest number sits in your tracker, unread: items committed versus items done, sprint after sprint. DORA's 2024 research frames the healthy loop as working in small batches with fast feedback; the low-performing tiers ship in large batches over months precisely because commitments and reality never get reconciled. Chronic carryover is that pathology at sprint scale. The feedback arrives every two weeks and gets ignored every two weeks.

The free cure: plan from measured throughput

One spreadsheet, six sprints of history you already have, one uncomfortable planning meeting.

1. Compute your carryover rate. For each of the last six sprints: committed at planning, completed at end, rolled forward. If the rolled share is chronically a quarter or more of the commitment, stop calling it ambition. It's a systematic measurement error with a sign that never flips.
2. Autopsy where the capacity went, without names. Sort the missed items into buckets: underestimated, blocked mid-sprint (on review, on a dependency, on a decision), displaced by unplanned intake, or never really started. The bucket distribution names the fix: estimates that never survive contact need slicing; review-blocked items need the review queue diagnosed; displacement needs an intake rule.
3. Commit to your measured throughput. If six sprints say the team finishes 11-14 items, the next commitment is about 12, and the stretch items are explicitly labeled stretch, below the line. This meeting is uncomfortable exactly once. After that, it's the meeting where plans started meaning something. A sprint-planning ritual built on real numbers survives contact with the sprint.
4. Reserve for unplanned work at your measured rate. Count what actually landed mid-sprint across those six sprints and hold that much capacity open. Reserving zero isn't optimism; it's pre-approving next sprint's carryover.
5. Make rolling expensive. Any item rolling a second time goes back to the backlog and gets re-argued, re-scoped, or killed - no silent third sprint. Combined with WIP limits, this closes the loop: less starts, more finishes, and the commitment converges on the truth.

Track one number after the change: carryover rate, six more sprints. If it's falling, your plans are becoming forecasts. If it isn't, the autopsy buckets tell you which mechanism you haven't actually fixed.

How you'd actually see this in Busfactor

Everything above runs on data your tracker and repo already hold, which is exactly why it's automatable, and why doing it by hand every sprint is the part that quietly stops happening by October. Busfactor connects to your tracker and GitHub and keeps the reconciliation running: estimate-versus-reality on tickets, measured weekly throughput with the commitment gap visible, and the delivery receipts (which items rolled, where they stalled, which stage ate them) linked to the actual tickets and PRs, in the same view as the rest of your delivery metrics. "We were a bit ambitious" becomes "we commit about a third above measured throughput, and the overflow is concentrated in review-blocked items." The second sentence is one somebody can act on.

The honest limits: this reads your tracker, so if tickets are fiction the reconciliation inherits the fiction. Garbage boards need hygiene before any tool's numbers deserve trust, ours included. Busfactor can show that carryover is chronic and where the missed items stalled; it cannot tell you which commitments were politically forced, over-sliced, or sandbagged. That's a conversation, and the SPACE authors' advice to pair metrics with actually asking the team remains correct and free. A forecast from measured throughput is a quoted range with stated assumptions, never a promise - any tool that gives you a date without the distribution is selling you the old ritual with better fonts.

The door

Six sprints, three columns, one afternoon: committed, completed, rolled. That spreadsheet will end the "a bit ambitious" era on its own, and it costs nothing. If you want the reconciliation to keep running after the afternoon ends, every sprint, with receipts, get your org's free read. The first thing it tells you is the size of the gap between what your org promises and what it measurably does. Most leaders guess wrong by a lot.