Sprint spillover: roll unfinished stories over, but do not re-estimate them

Roll the story over. That part is fine. The mistake most teams make on the last day of a sprint is the thing they do next: open the unfinished story, look at how much is left, and change the number.

That is the argument of this whole post, stated plainly before the defence. Carrying work across a sprint boundary is a normal, unavoidable consequence of drawing a boundary. Re-estimating that work on the way across is a small act of bookkeeping that quietly destroys the one piece of evidence you needed. The story was an 8. It did not finish. Both of those facts are useful. Shave it to a 3 because "most of it is done" and you have thrown away the second one before anybody could look at it.

What is sprint spillover, and when is it actually a problem?

Sprint spillover is planned work that was not finished when the sprint ended. That is all the word means. The interesting question is not whether you have it but whether it is the same size every time.

One story slipping because a dependency arrived late is weather. It needs no ceremony and no root cause analysis. Mike Cohn makes this point well in his piece on breaking the unfinished-work habit: a team that aims high and lands slightly short is doing something worth encouraging, not correcting. Occasional spillover is the cost of an ambitious sprint goal, and a team that never spills is probably committing to less than it could.

Three stories, every sprint, for six sprints, is not weather. It is a climate, and the thing that makes it dangerous is not the lost points. It is that it stops being visible. Nobody announces it. It happens in the four seconds it takes to confirm a dialog on a Friday afternoon, and by Monday those three stories look exactly like the rest of the plan.

Put real numbers on it, because the numbers are worse than the feeling. Say your team's velocity sits around 23 points. The three stories that roll are an 8, a 5 and a 3. Sixteen of your twenty-three points of capacity are spent before anyone opens the backlog. You are planning about a third of a sprint and calling it a sprint, and then you are surprised when the sprint goal keeps not landing. It was never a two-week goal. It was a five-day goal with a two-week label on it.

The Guide gives you a decision, not a conveyor belt

Worth checking what Scrum actually asks for here, because it is more specific than most teams remember and less prescriptive than most teams fear.

The 2020 Scrum Guide addresses incomplete work in exactly one sentence: "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration." Read the last three words slowly. Not "returns to the next Sprint". Returns to the Product Backlog, for consideration. The Guide is describing a decision that gets made again at the next planning session, by people who now know something they did not know two weeks ago.

What the Guide does not contain is just as useful. The words spillover, carry over, velocity and re-estimate appear nowhere in it. Nothing in Scrum tells you to recalculate the remaining effort on a story that missed, and nothing tells you not to. That makes this practitioner territory, and the practitioners are genuinely split.

One camp, well represented in the Scrum.org community forums, says the remaining work should be re-estimated before the item is brought back into a sprint, so the team pulls in the right amount. The other camp refuses point blank. Joel Bancroft-Connors, writing for Scrum Alliance, puts it about as flatly as it can be put: "I never re-estimate work that is not completed." Both of those are considered opinions from experienced people rather than framework rules, which means you have to actually pick. We are firmly in the second camp.

Should you re-estimate an unfinished story?

No, not for the reason you want to. Here is the case against.

An estimate is a claim about the size of a piece of work. The moment you allow that number to be revised downward because part of the work already happened, the number changes meaning. Your backlog now contains 8-point stories that mean "this is an 8-sized job" sitting next to 3-point stories that mean "this was an 8-sized job and there is about a 3 left". Same field, same scale, two different units. Every downstream thing that reads those numbers, planning, forecasting, the argument about whether next sprint's commitment is realistic, is now averaging apples and remainders.

The second cost is the one we care about more. A story that missed the sprint is a piece of evidence. It is telling you the size was wrong, or the story was too big to fit in the box, or it entered the sprint with an unanswered question inside it. Re-estimating it to reflect the remainder resolves that evidence into a tidy small number that looks fine on the board. The story stops looking like a problem and starts looking like next week's easy win. Do that three times a sprint and your board is a permanent record of the work being nearly done, and never a record of the work being badly sized. Our sibling post on sprint velocity explains why the arithmetic breaks too, and we will leave that argument to it.

Now the concession, because there are two cases where changing the number is the right call.

The first is when you genuinely learned that the whole story is a different size. You opened the feature, discovered the legacy integration underneath it, and the entire job is a 13 rather than a 5. That is not re-estimating for progress, that is correcting an estimate that was wrong on its own terms, and it should go up as often as it goes down.

The second is a real split. If a genuinely separable slice of the story is finished and meets your definition of done on its own, you can split the story into a done part and a remaining part, with the two estimates adding up to the original. Five points shipped, three points carried, eight points total. That is honest. The trap is that this qualifies far less often than teams want it to. Most half-finished stories are not a shippable slice plus a remainder, they are one indivisible thing in a partly-refactored state, and splitting them at the boundary is a bookkeeping story you tell yourself to make the sprint look better. If the "done" half cannot be released without the other half, it is not done, and the split is fiction.

What to do with unfinished stories at the end of a sprint

So if the answer is not to re-estimate, what is the actual work on the last day? Three decisions, and only the first one usually gets skipped.

Start by deciding whether each story still deserves to exist. This is the step the tooling steals from you. Some of those three stories are genuinely worth finishing on Monday. At least one is a thing you wanted two weeks ago and would not choose today, and the only reason it is still alive is that rolling it forward took no effort at all. Cancel it, explicitly, where the team can see you do it. A cancelled story is a decision. A story on its fourth sprint is an accident that keeps happening.

Then move the survivors at their original size, and put them at the top rather than slotting them into the new plan by priority. A story that spilled once and then got outranked by fresh work will spill again. A story on its third sprint has usually been sitting at position seven of ten the entire time, which is the actual reason it keeps missing, and no amount of re-estimating it will change that.

Last, write down the count before you close the sprint. Not the reasons, not a narrative. Just how many stories moved and what they were worth. Sixteen points across three stories. That number, tracked for three or four sprints, is the only version of this problem a retrospective can act on. "We keep not finishing things" produces sympathy and a vague resolution. "We have started each of the last four sprints with two thirds of our capacity already committed" produces a change.

Why habitual spillover is a refinement problem

Here is where we changed our mind, and it took a while.

We used to read chronic spillover as a commitment problem. The team over-commits, so the fix is to commit less: pull fewer points, deliberately undershoot, let everyone experience finishing a sprint again. That advice is widespread and it is not wrong exactly. It works. For about two sprints. Then the same team, with the same backlog, quietly re-inflates to the same commitment, because nothing about the work changed. You cannot fix a container problem by putting less in the container when the individual items are still bigger than the container.

The thing that actually correlates with a team that finishes its sprints is story size, and the second thing is how much was unresolved when the story entered. A 13-point story in a two-week sprint has to go perfectly to land, and it has roughly a week of slack for anything to go wrong before it becomes next sprint's problem. A story that entered planning with an open product question in it will spend two or three days waiting for an answer, which on a ten-day sprint is a quarter of its life. Neither of those is a discipline failure. Both are things you decide before the sprint starts, which is to say both are refinement decisions.

So the honest diagnosis for a team rolling three stories a sprint is usually one of these. The stories are too large, and need splitting until nothing bigger than about a third of a sprint enters the sprint. Or the bar for entry is too low, and "ready" currently means somebody wrote a title. Or the sprint is the wrong length for how your team actually works, which is a real possibility worth taking seriously rather than a cop-out, and is the subject of its own post.

Notice that all three of those are fixed before the sprint, not on the last day of it. The last day is where you find out.

What the last day looks like in Scrumpy, including the part we made too convenient

We should be straight about our own tool here, because Scrumpy makes exactly the mistake this post is about, deliberately, and it is worth naming.

Ending a sprint in Scrumpy takes every story that is not done and moves it into the next planned sprint. If no planned sprint exists, it creates one and names it for you. The confirmation dialog says one sentence, "Stories not marked as done will be moved to the next planned sprint", and then you click a button and it is Monday. That is convenient, and convenience is precisely how three stories a sprint becomes invisible. The Guide's "for future consideration" is the step our own button skips. So use the dialog as your prompt to do the deciding first: go through the open stories before you end the sprint, not after.

Two details that support doing it that way. The default board ships with a "Won't do" lane that lives off the board and is marked as cancelled, and cancelled is the one state an ending sprint does not carry forward. Done stories stay put, cancelled stories stay put, everything else moves. That lane is the escape hatch for decision one, and it is worth using it out loud rather than letting a story quietly ride along.

The other is that a finished sprint keeps a record of the total points it was carrying, stamped at the moment you ended it. Without that, a completed sprint's history would lie to you: the stories left, so a naive total would only ever show what stayed behind, and every sprint you spilled from would look smaller and tidier than it was. The scope you committed to is preserved, which means the gap between committed and finished is still visible weeks later. That gap, over five or six sprints, is the picture you want in front of the team.

And the uncomfortable option. If your team spills every sprint, and you have had three honest retrospectives about it, and the number has not moved, consider that the sprint may not be doing anything for you. A boundary you cross with unfinished work every single time is not a commitment device, it is a fortnightly ritual with a rollover attached. Sprints in Scrumpy can be switched off per team, which turns the board into a continuous flow: story points stop being required, and resolved tickets archive themselves off the board a week after they land instead of waiting for a sprint to end. We named the product after scrum and we will still tell you to turn the sprints off, because a board you trust beats a ceremony you have stopped believing in.

The homework

At the end of your next sprint, before you press the button, write down two numbers: how many stories are moving, and what they add up to in points. Do not change any of the estimates. Do it again the sprint after, and the one after that.

If the number is flat across three sprints, you have your answer, and now you have it in a form you can say out loud in a room without it sounding like a complaint about anyone. If it is falling, refinement is working and you should leave it alone. And if you want the board to keep that record for you instead of a note in your phone, start a team and run one sprint through to the end properly. The last day is the only day that tells you the truth about the previous nine.