Unfinished Sprint Work: How to Handle Rollover Without Lying to Yourself

Sprint rollover is unfinished sprint work that moves into the next sprint. Treat it as new work: put it back in the backlog, split off what is left, and estimate only the remainder before you plan. If you copy the old story with its old points, the next sprint starts with a number nobody can still earn.

Why an incomplete sprint is normal

A sprint is a forecast, and forecasts miss. People get sick, a dependency slips, and one screen turns into three states plus a permission check nobody mentioned. The Scrum Guide treats the sprint backlog as a plan the team updates as it learns. The team and the product owner decide what happens to work that is not done.

An incomplete sprint tells you the slice was too big, the goal was fuzzy, or the team agreed to more than the calendar could hold. It says nothing about the people. The damage starts when the board hides that: old points stay green, velocity keeps rising, and next week's capacity counts work as done when it only looks done on paper.

If your definition of done includes review, tests, and something a user can open, then a story sitting in review is not finished. Neither is a pull request with open comments. "Ninety percent" is a guess, and a guess isn't a status.

When sprint rollover is the right call

Roll a story when the remaining work still serves the next sprint goal and someone can describe the unfinished part in one sentence. Leave it behind when the goal has moved, when the remainder is really a new idea, or when the story has been almost done for more than one sprint.

Ask four questions before you carry anything:

1. Is the remaining work still the smallest slice that finishes the original outcome?
2. Can a developer who wasn't on it yesterday pick it up from the notes, the branch, and the acceptance criteria?
3. Does it still belong to the next sprint goal, or is it left over from a goal you already dropped?
4. Would you accept this story if it showed up today with no history?

If the last answer is no, being on the board already doesn't earn it a spot. Put it back and let it compete.

Don't roll a story to protect a chart. Don't roll it because someone has needed "one more day" for three Fridays, or because a bug, a spike, and a feature share a title. Splitting takes a few minutes, while a muddled story eats the next ten days.

How to carry over stories without double-counting

Carry over stories only after you separate finished work from what is left. The original story keeps the points you already counted, and only if that part meets your definition of done. The new story gets a fresh estimate for the remainder. A card with open work should never keep its original points.

Points forecast effort you haven't spent yet, and done work is already history. Mix the two and velocity looks smooth while the plan drifts.

A simple accounting rule

What happened	Where the points go	What you plan next
Story meets the definition of done	Count them in the sprint where it finished	Nothing
A usable slice shipped, and the rest is real	Count only the finished slice, if you split it	Estimate the remainder as a new story
Nothing usable shipped	Count zero	Re-estimate the whole story, or delete it
Scope grew mid-sprint	Count the original slice if it is done	New scope is a new story with its own estimate

If your tool can't split a story without losing the discussion, write the remainder as a new ticket and link the two. The link keeps the history and the new estimate drives the plan. "Move to next sprint" keeps the old number unless you change it.

A carried story starts the next sprint in ready, and people pull it when they start on it. A Monday full of in-progress cards hides what actually started this week.

Reviewed rollover means a person looks at each item and accepts the move. Automatic rollover, where every open card jumps forward at midnight, skips that review. Go down a short list, say yes or no, and give each item a new estimate.

A worked example

A team of five plans 40 points. On Friday, three stories are not done.

Story A, "Export invoices to CSV," 8 points. One month exports, but large accounts time out, so it isn't safe to turn on. Count 0. Split it into "Export one month, tested on a large account" at 5 and "Stream the file so big accounts do not time out" at 5. Pull only the first, because the goal is "close the books for pilot customers" and the pilot files are small.

Story B, "Invite a teammate," 5 points. The invite path is in production. The empty-state copy is still a placeholder, and the definition of done includes it. Count 3 for what shipped, then open a 2-point story for the copy and pull it. Support is already fielding the questions.

Story C, "Redo the settings page," 13 points. Two of six sections sit behind a flag, and the goal never depended on settings. Count 0 and don't carry the 13. Next time, cut it to one section a user can open, or leave the epic alone. "We already started" is not a reason to spend another sprint on it.

Don't add 8 + 5 + 13 onto the next commitment. Plan from capacity, then pull the 5-point export and the 2-point copy if those still rank. Velocity for the closed sprint is the points that met done, not 40.

What to tell leadership

Keep it to one breath: "We forecast 40. We finished 24. Eight was an export that timed out, and thirteen was a settings page we should not have started."

A point can't be both spent and still available. If you forecast from the inflated number, the next sprint is late before it starts. One low sprint nudges the average. Three in a row mean the slices are too big or the plan is wishful. Fix that in how you plan the sprint, not with a twelve-state rollover policy.

Where rollover shows up in planning

Start with capacity: holidays, on-call, and meetings you already know about. Carried work is a candidate, not a pre-filled commitment. A sprint planning template that opens on leftovers trains the room to defend the past, so open with the goal instead.

The sprint backlog is what you intend to finish for this goal. Leftovers stay on the product backlog until they earn a place. Check whether there's a sprint goal someone still remembers on day six, and whether the remainder serves it.

1. Read the goal. Without one, carried work becomes a second backlog ranked by seniority.
2. Say in one sentence what is left. If you can't, it isn't ready to move.
3. Split or discard. Count finished slices once, estimate remainders as new work, and delete dead scope.
4. Use planning poker when people disagree about the remainder. Skip it for an afternoon everyone agrees on.
5. Stop when capacity runs out. Some carried stories will wait.

If that list doesn't fit, stop estimating new epics in the same hour. A long unfinished list means you're rolling too much. Some tools keep the old issue and the old estimate, so change both yourself.

What the board is telling you

A story that has rolled twice is older than your sprint for a reason. Usually the acceptance criteria describe a project, review happens in batches, or one person holds the context. Closing the card harder won't fix that.

If in progress is full on day one and still full on day ten, the team is storing work. If median cycle time is longer than the sprint, stories will keep rolling until the slices get smaller. A longer sprint only hides the problem.

Forecast from finished work, because points counted twice give you a date you've already missed. Cycle time, cumulative flow, and a Monte Carlo forecast should use completed items. Falrow runs that from ticket history (2,000 runs). A spreadsheet works too, as long as carried points stay out of it.

A policy that fits on one page

• A story rolls only after a person accepts it. Nothing moves on its own at midnight.
• Only done points count, and they count once. The remainder gets a new estimate.
• Status resets to ready. The next sprint starts with an empty in-progress column.
• A third rollover means you split it smaller or drop it.
• Carried work competes with new work. It does not sit above the goal.

Falrow cycles work this way: each open item has to be accepted into the next cycle. The same rules work on a whiteboard. Review is the default, rather than "move everything and keep the points," and that setting lives under cycle schedules and reviewed rollover.

Monday shouldn't open on a wall of half-done cards. The number you report is what actually finished, and you defend it with the story: the export timed out, and a smaller export is in this sprint. If every hard story rolls and every easy one finishes, pull one hard remainder early. Leave it until Thursday and it will roll again.

Sprint rollover is a planning choice a person makes, and the tool shouldn't make it for you at midnight.

FAQ

Should you always move unfinished stories into the next sprint?

No. Move a story when the remainder still matches the next sprint goal and you can estimate what is left. If the goal changed, or there is no usable slice and no clear remainder, put it back on the product backlog. Automatic moves keep stale work ahead of better work.

Do you re-estimate stories you carry over?

Yes. Estimate only what remains, and count finished points at most once. Copying the original estimate makes velocity look better than what shipped and makes the next forecast late. If the remainder is unclear, it isn't ready to roll.

Does sprint rollover mean the team failed?

It means the forecast was wrong or the sprint changed. One incomplete sprint is normal. When the same stories roll again, the slices are bigger than the sprint, or the team starts more than it finishes. Check story size and unplanned work.

Should carried work be planned before new work?

Only when it's the best way to reach the sprint goal. Age can break a tie, but it shouldn't set the ranking. A story that has waited two sprints deserves a decision: shrink it or drop it. Putting leftovers first means the team stops choosing.