Every few weeks the same argument resurfaces in Agile forums: a story was 90% finished when the sprint closed, it rolls into the next sprint, and somebody asks whether the team should re-estimate carryover stories or carry the original number across untouched. Practitioners line up on both sides with real conviction. One camp says re-estimating rewards sandbagging and corrupts velocity history. The other says carrying an eight-point story that has two points of work left is simply lying to the plan.
Both camps are right about something, and both are answering a question they have not agreed on. Before you can decide whether to re-estimate carryover stories, you have to decide what the estimate is for.
Two numbers wearing the same name
A story point does two unrelated jobs on most teams. It is a measurement of delivered value feeding velocity, and it is a planning input for how much capacity the next sprint has to spend. The re-estimation debate is a collision between those two jobs.
If the point is a measurement, do not touch it. Velocity only means something if the unit stays constant. Re-sizing a story mid-flight so it fits the sprint you are currently planning is the estimation equivalent of moving the finish line, and it will make your throughput history useless for forecasting.
If the point is a planning input, the original number is now actively wrong. Nobody is going to spend eight points of effort on a story that needs a code review and a deploy. Loading the next sprint against a stale number means you will under-fill the sprint and then wonder why the team finished early and pulled unplanned work.
The rule that resolves it
Keep the original estimate for credit. Plan against remaining effort.
Concretely: the story keeps its eight points, and the eight points are credited to whichever sprint actually closes it. Velocity history stays honest, and no sprint gets partial credit for unfinished work — the widely held Scrum position that an undelivered story delivered nothing holds. But when you plan the next sprint, you count the two points of remaining work against available capacity, not eight. The commitment is sized against reality; the scoreboard is not.
This needs one piece of discipline to work: the remaining-effort number has to be a deliberate estimate the team says out loud in planning, not a field somebody guesses at. That is a thirty-second conversation per carried story, and it is the single cheapest planning improvement most teams have available.
Re-estimating is a symptom, not the disease
If this debate comes up every sprint, the estimation question is not your real problem. Recurring carryover almost always traces to one of three causes, and none of them are fixed by changing a number:
- Stories are too large to finish inside one sprint. A story that routinely spans a sprint boundary was never sliced thin enough. Vertical slices that each deliver something demonstrable are the fix, and that work belongs in refinement, not planning.
- The team committed to velocity instead of capacity. Velocity assumes a full team for a full sprint. Holidays, support rotations, interviews, and meetings routinely remove a third of it, and the gap comes out as carryover.
- Acceptance criteria kept growing. If the definition of the story changed after it was sized, the estimate is not stale — the story is new. That one genuinely should be re-estimated, and the change should be visible.
Worth watching for: if 30–40% of the original forecast fails to land sprint after sprint, the team has stopped running Scrum and started running time-boxed Kanban with extra ceremonies. That is a fine way to work, but it should be a decision rather than a drift.
Where the carryover actually costs you
The estimation argument gets the attention, but the expensive part of carryover happens one level up. Each carried story quietly consumes capacity in a sprint that was already committed to other work, and that displaced work pushes into the sprint after it. Four sprints later the release date has moved and nobody can point to the meeting where it happened. We traced that mechanism in detail in sprint spillover and the committed release date.
Making it visible in Jira
The reason teams argue about the number instead of the capacity is that the capacity is usually invisible at the moment of decision. Sprint Planning, Capacity & Resource Planning for Jira puts each person’s real availability — PTO, part-time allocation, support duty — next to the work being pulled in, so a carried story’s remaining effort lands against hours the team actually has rather than an average. When the remaining work exceeds capacity, you see it in planning instead of in the retrospective.
Upstream, Backlog Refinement, Sprint & Capacity Planning for Jira attacks the root cause: stories that arrive at planning already sliced and sized are the ones that finish inside the sprint. Most carryover is a refinement debt paid at planning time.
The short version
Do not re-estimate carryover stories for the purpose of velocity — the original number is the record. Do estimate the remaining work for the purpose of planning, out loud, every time. And if you are having this conversation every sprint, fix the slicing and the capacity check rather than the arithmetic.
The capacity check underneath all of this is the part worth getting right: the sprint goal, the velocity history, the days people are actually available, and filling the sprint without over-committing. Our step-by-step guide to planning a sprint against real capacity in Jira walks through that sequence, carryover included.
Part of our guide: this article is a deep dive from the complete guide to sprint planning for Agile teams. See also story points vs hours for the underlying estimation choice, common sprint planning mistakes for the traps that create carryover in the first place, and sprint commitment vs forecast for what the team is actually promising. For how these show up on government and public-sector teams, see sprint planning anti-patterns.
Leave a Reply
Your email is safe with us.