Spillover

Working in fixed-length cycles means that on the last day, work divides into finished and unfinished. The sprint, a fixed-length work cycle with a commitment to deliver at the end, is that frame.

The trouble was that language went soft at exactly that boundary. Ask about a remaining item in the last meeting of the cycle and the answer is that it's almost done. Almost has no definition, so the item slides quietly into the next cycle, and on the last day of that cycle the answer is the same. One item sits in progress for a third cycle while the report says 90 percent every week, and nobody can say when the remaining ten percent will land.

At that point the reason for having cycles is gone. The purpose was to count how much gets finished per cycle and use that as the basis for the next plan, and with finished left vague there is nothing to count. Plans always look like they held, and the amount of software actually shipping falls. The gap shows up eventually, usually as a missed date told to someone outside the team.

Spillover names that soft spot so it can be counted. Call carried work carried work, record how many items and how large, and how far ahead of reality the plan was stays on the record as a number.

It starts by splitting items in two the moment the cycle ends. The test is the definition of done (DoD) the team agreed on in advance, usually something like reviewed, tested, and running in production.

1. Collect the items that didn't meet the definition. Work that's built but waiting on review belongs here, and so does anything a customer hasn't been able to touch yet.
2. Score those items zero. Award 7 points for an 8-point item that's 90 percent there and every cycle total comes in higher than reality, and the next plan built on the inflated number slips again. The carried item collects its full 8 points in the cycle where it actually finishes.
3. Record the count and the point total of what carried. Carried points against committed points is the cycle's spillover: commit 40 and carry 6 and that's 15 percent.
4. Classify the reasons. Sized wrong, waiting on another team or an outside answer, requirements changed mid-cycle, someone left, urgent work cut in. Counting incidents without reasons guarantees the same thing next cycle, because the number alone suggests only one remedy: commit less.
5. Seat the carried items first in the next plan, and commit new work only against what headroom remains. Add new work without counting the carry-in and the load compounds cycle over cycle.

There's a way to read the percentage. Under 10 percent is normal; slicing work into cycles always leaves items straddling the boundary. Past 30 percent, trimming the plan a little doesn't fix it, and the structure deserves a look — how large items get sliced, how long the cycle is. Accumulating spillover automatically drags down velocity, the average amount finished per cycle, so reading the two together separates an inflated plan from blocked execution. Rising spillover with flat velocity points at the plan; both falling points at something in the way.

Three places use it as an input.

The first is sprint planning, the meeting that decides what this cycle contains, which starts with the carried items already on the board. Three cycles of spillover in the twenties is where the decision to commit less comes from. The first line of the sprint backlog, the set of work pulled in for this cycle, is frequently a carried item.

The second is the retrospective, the session for examining how the team works and deciding what to change. The reasons classified in step 4 become the agenda directly. If waiting on an outside answer caused it three cycles running, what needs fixing isn't the team's pace but the procedure around that wait.

The third is deciding how much to have open at once. A work-in-progress limit, a cap on how many items can be in flight, gets its justification from spillover. Five people holding seven items at once finish the cycle with seven items at 80 percent. Finishing them one at a time ends with five done and two carried. Less carries, and more ships — the same people, the same cycle, a different amount of work open at once.

"Spillover was 6 points this cycle, so we'll commit 34 next."

Subtracting the carry-in before deciding how much new work to take.

"This item carries at zero, no partial credit."

Confirming the principle that almost done earns nothing.

"Spillover has been outside-wait three cycles running. This isn't a pace problem."

Pointing out that the cause sits outside the team, so the fix is procedural rather than trimming the plan.

At Pagedeck, the shape of the conversation changed after Mia started recording the spillover percentage each cycle. Before that, the last meeting went item by item asking how much was left, and the answer was generally that it was almost done. The first three cycles with a number came in at 28, 31, and 24 percent.

Classifying the reasons put half of it on sizing and the rest on outside waits. For sizing, items above 8 points get split during planning. For waits, Theo moved requests to other teams to before the cycle starts. Four months later the percentage was running between 9 and 13, and the last meeting of the cycle stopped being an estimate exercise.

The most common misreading is that a good team has zero spillover. Nothing carried means the plan held, which is a natural inference. But there are generally two ways to reach zero: commit very little, or apply the definition of done loosely on the last day and call things finished. The first leaves a team doing less than it can; the second records work as done with review and testing missing. A few months later the second one comes back as a production incident, traced to a change that was marked done in a cycle nobody remembers.

Reading carried work as a diligence problem is the other one. A name sits next to each item, so it looks that way. But classified, the causes are mostly mis-sizing and waiting on others, and both belong to planning and process. Put the cause on individuals and from the next cycle people commit only what they're sure to finish, or say it's almost done — and at that moment the number stops measuring anything. What a team reports and what a team does come apart, and the reporting is the half that looks healthy.