What to do with carryover stories when calculating velocity

A story worth eight points is nearly finished when the sprint ends. It rolls into the next sprint and closes on day two. Your velocity chart now shows one sprint that undershot and one that overshot, and neither number describes what the team actually did.

This is the most common way velocity stops being useful, and the usual fix — awarding partial credit — makes it worse. Here is what actually goes wrong, and the two approaches that are defensible.

Why partial credit is the wrong fix

The instinct is to award five of the eight points in the first sprint and three in the second. It feels fair. It is also the one approach essentially every source agrees is wrong.

Mike Cohn’s argument is blunt: don’t take partial credit for semi-finished stories. The Scrum.org position is the same: items are complete or they are not, and teams should not spend effort assessing what percentage of a story got done.

The reasoning is practical rather than dogmatic:

• It inflates velocity. Partial credit counts work that delivered nothing usable. Forecasts built on it promise capacity the team has never actually demonstrated.
• The estimate is unreliable at exactly the wrong moment. “About 60% done” is a guess about the easy part being finished. The remaining 40% is usually where the integration work, the edge cases and the review comments live.
• It costs real time. Every sprint boundary turns into a negotiation about percentages, which is time spent on accounting rather than on the work.

Velocity measures completed, potentially shippable work. A story that does not ship contributed zero to that sprint, however much effort went into it. That feels harsh and is the entire point — it is what keeps the number honest.

The two defensible approaches

Once partial credit is off the table, sources genuinely disagree about what to do with the carried-over story. Both options below are reasonable; they optimise for different things.

Option A — full points when it completes

The story keeps its original eight points and scores all eight in whichever sprint it finally closes. Sprint one records zero for it, sprint two records eight.

The per-sprint numbers are noisy, but nothing is lost: across any two sprints the totals are correct, and a rolling average smooths the spikes out. Critically, the points you forecast with stay comparable to the points you estimated with.

Option B — re-estimate the remainder

The Scrum.org forums lean toward this: return the item to the backlog re-estimated for the effort and complexity that actually remain. Eight points of work with most of it done might come back as three.

This gives a truer picture of upcoming capacity. The cost is that five points of genuinely completed work vanish from your records entirely — the team’s measured throughput now understates what it delivered, and your velocity is no longer denominated in the same units as your backlog estimates.

Which to pick

For most teams, Option A. It requires no extra ceremony, it keeps velocity and backlog estimates in the same units, and its main flaw — noisy individual sprints — is solved by the three-sprint average you should be forecasting with anyway.

Option B earns its overhead when carryover items are large and frequently half-finished, and when you are forecasting a specific date rather than tracking a trend. If you choose it, choose it permanently. Switching between the two mid-way makes every historical number incomparable.

Reading an average that contains carryover

Whichever option you pick, one rule holds: never forecast from a single sprint that contained carryover. Take the last three completed sprints and average them.

Say your last four sprints ran 21, 13, 29 and 22 points, and the 13/29 pair was a single large story slipping across the boundary. Reading sprint three as “29 — the team is speeding up” is the classic error. The honest reading is that the team averages around 21, with one sprint distorted by an item that should have been split.

A useful sanity check: if removing your largest single story changes a sprint’s total by more than about a third, that sprint is not a data point. It is one story wearing a sprint’s clothing.

Our sprint velocity calculator does this arithmetic for you, and deliberately reports a forecast range bounded by your best and worst recent sprints rather than a single number.

When carryover is a symptom, not an event

One story slipping is normal. Something slipping every sprint is a sizing problem wearing a velocity problem’s clothes, and no accounting convention will fix it. The consistent advice across every source above is to attack the cause: split the work smaller so less of it can be in flight when the sprint ends.

Signals worth watching:

• The same story carries over twice — it is not one story.
• Any single item is more than about a third of the sprint commitment, so its slipping swings the whole sprint.
• Carryover clusters on one person, which is a dependency or a review bottleneck rather than an estimation error.
• Items are “done” but unreviewed at the boundary — that is a definition-of-done problem, and it will keep recurring until the definition changes.

What Sprint Guage does, and what it cannot

Closing a sprint in Sprint Guage moves every unfinished item in one step — either into a sprint you nominate or back to the backlog — so nothing is silently stranded at the boundary. Velocity counts only items that reached a done status, at their full story points: Option A by default, with no partial credit available anywhere in the product.

What it will not do is decide for you. Re-estimating a carried-over item is a judgement about work you understand better than any tool does, so the rollover preserves the original estimate and leaves changing it to you. Sprint history and the velocity chart then show which sprints contained carryover, which is the context you need before reading any average.

If you want to see that on your own backlog rather than a demo, start a trial — sprint history and velocity are on every plan.