The Story Is Too Big: How Refinement Decides Delivery

There is a sentence that turns up in almost every delivery post-mortem I have read in the last two years. The story turned out to be bigger than we thought. It is offered as an explanation, and it is really a confession. The team did not misjudge the size of the work. The thing sitting in their backlog was not a story, and no amount of estimating was going to make it fit.

Here is the version I see most often. A card gets estimated at three days. Two weeks later it is still open and the conversation has moved from build to design to we should probably loop in legal. It finishes seven weeks after it started, having eaten parts of three other people's sprints along the way. The retro blames scope, or the product owner, or the discovery that the integration was harder than it looked. None of those is the cause. The cause is that nobody ever drew a boundary around the work, so there was never a moment at which it could have been declared done.

Size is not a property of the work. It is a decision a team makes about where the work stops, and the practice that makes the decision is backlog refinement. Refinement is the least glamorous ceremony in agile, which is why it gets skipped, shortened, or converted into a status meeting about the backlog. It is also, in 2026, the one that matters most, because the machinery that generates work got dramatically faster and the machinery that reviews it did not.

What refinement actually is

The 2020 Scrum Guide uses the word "ready" exactly once. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event, and the same passage defines refinement as the act of breaking down and further defining items into smaller, more precise items¹. That is the entire mandate, and it carries two ideas teams routinely miss.

The first is that readiness is a property of an item, not of a backlog. There is no such thing as a ready backlog, because a backlog is a living artifact and change is expected at every level¹.

The second is that refinement is not a gate. Most teams turn readiness into a Definition of Ready checklist and then hand the checklist to a bouncer. Scrum.org's Joanna Płaskonka catalogs the failure signs: paralysis in sprint planning when the checklist is unmet, blame games, a Definition of Ready owned only by the product owner or the business analyst, more attention paid to the front gate than to producing a done increment, and a loss of flexibility once an item has been stamped ready¹. Her own recommendation is telling. She would rather call the practice refinement discussion points, because "Definition of" sounds like a commitment when it is a supporting practice¹.

The distinction from the Definition of Done is the whole point. Done is a commitment in Scrum; ready is a conversation¹. Done tells you what the increment has to satisfy before it ships. Ready is a team's honest answer to one question, and Mike Cohn states it more plainly than anyone else: do we understand this item well enough to believe it will fit in a sprint²? When the answer is yes, you stop refining that item.

Refine to confidence, not to certainty

Cohn's threshold model describes the two ways refinement goes wrong. Under-invest and the symptoms surface downstream: sprint planning runs long, stories turn out larger than expected, items get split during planning instead of before it, edge cases appear late, and the team leaves planning exhausted and then misses the goal. Over-invest and you buy something equally expensive: analysis paralysis, effort spent on work that may never be built, and false precision².

His stopping condition is the cleanest one available. Stop refining when the team knows the item will fit in a sprint. That is confidence, not a guarantee. If an unresolved issue could dramatically increase the size of the work, resolve it before the item enters the sprint. If the remaining uncertainty is small and unlikely to derail the sprint, carry it into development and stop talking about it².

The shape of a healthy backlog follows from that rule. Cohn calls it a clarity gradient: detailed at the top, deliberately vague at the bottom, closer to an iceberg than a shelf. Items starting in the next sprint or two carry clarified assumptions and acceptance criteria. Items further out stay flexible on purpose, because over-detailing them is work you will throw away when priorities move².

He offers three diagnostics. Sprint goals achieved about 80% of the time, since a team hitting 100% is playing it safe and a team missing often has a refinement problem rather than a planning problem. A visible clarity gradient in the backlog. And low carryover, because unfinished work crossing a sprint boundary is the signature of items that were never small enough in the first place².

The mechanics are simpler than the philosophy. Refinement is the ongoing work of reviewing, ranking, and editing the backlog. Near-term items get complete stories, with design and development collaboration finished and an estimate attached, while longer-term items stay vague³. Atlassian's practical cadence is about 30 minutes before each sprint planning session, run by the product owner, with at least one representative from development and one from QA in the room³.

The slice has a shape, and the shape is vertical

A backlog item is a description of a change in system behavior from the perspective of a user⁴. That definition disqualifies a large fraction of what teams call stories. A database migration with "as a developer" pasted on the front is still a task.

The distinction that does the work here is vertical versus horizontal. A vertical slice is a work item that delivers a valuable change in system behavior, which usually means it touches several architectural layers. When you call it done, the system is observably more valuable to a user. A horizontal slice changes one component or layer and only produces value after it is combined with changes elsewhere⁴.

Teams split horizontally because layers map onto skills. There is a database person, a UI person, a services person, so the work gets cut along those lines and everyone starts in parallel. The trouble is that the value only exists where the layers meet, so handoffs and coordination arrive exactly where the schedule is thinnest. Visual Paradigm's cake analogy is the one to keep: nobody eats a cake layer by layer, you cut it into slices that each contain a bit of every layer⁵. The organizational version is the difference between component teams, which own layers and pass work to each other in series, and feature teams, which own the whole slice and can finish it⁵.

The nine patterns, and the meta-pattern under them

Once you accept that a slice should be vertical, the practical question is where to cut. Humanizing Work's flowchart tries nine patterns in order: workflow steps, operations, business rule variations, variations in data, data entry methods, major effort, simple versus complex, defer performance, and break out a spike⁴. Mike Cohn's SPIDR covers the same ground as a five-item mnemonic, Spike, Path, Interface, Data, Rules, which he derived by printing a thousand stories collected over fifteen years and grouping the ways they had actually been split⁶.

A worked example makes the order concrete. The card reads: as a content manager, I can publish a news story to the corporate website. It does not sound large. Then you trace what publishing requires, and it turns out to involve editorial approval, legal approval, and a separate review pass on a staging site. The obvious split, one workflow step at a time from beginning to end, is the wrong one. The pattern that works builds the simple end-to-end case first and adds the approval steps and special cases afterward, because in a workflow the value concentrates at the beginning and the end⁴.

The rule most teams get backwards is where the spike sits. Investigation is the last resort, not the first move. You usually know enough to build something, and building it teaches you more than another meeting would. Only when the implementation is genuinely poorly understood does a time-boxed spike go first, with the questions you need answered written down as its acceptance criteria⁴.

Underneath all nine patterns is a single meta-pattern: find the core complexity, identify the variations, and reduce the variations to one. The variations are the usual suspects, business rules, user types, interfaces, data shapes, entities. Collapsing a source of variation to one complete slice is what almost every pattern is actually doing⁴.

The test to apply after any split is INVEST: independent, negotiable, valuable, estimable, small, and testable¹⁴. Humanizing Work's operational reading of small is that by the time an item reaches the top of the backlog, you should be able to fit six to ten of them into a sprint, a ratio that scales with sprint length and team size⁴. They are also honest that the criteria pull against each other. As items get smaller they get harder to keep independent and valuable. As they get more negotiable they get harder to estimate and test. Near the top of the backlog, small, estimable, and testable is what matters. Further out, independence and value take over⁴.

The AI reversal

DORA's 2025 research found AI adoption near universal, with 90% of survey respondents using AI at work, and, unlike the prior year, a positive relationship between AI adoption and delivery throughput. The relationship with stability stayed negative⁷. The companion report puts numbers on it: a 25% increase in AI adoption is associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, and it names the mechanism. Because AI lets developers generate code much faster, it often produces larger batch sizes, which are slower to review and more likely to create system instability⁸.

That sentence describes a refinement problem wearing an infrastructure costume. The generator got faster. The reviewer did not. When generation is cheap, the constraint moves to review, verification, and integration, and review cost scales with the size of the batch while the value of the batch does not. DORA's own recommendation is to strengthen fast feedback loops, automated testing and quick reviews, precisely so that AI-introduced errors are caught before production⁸.

Cohn's 2026 position lands in the same place from the agile side. AI can draft backlog items and propose splits, but refinement has to stay human-led, because only a person can judge whether an item carries the right amount of detail and whether the intent is right. His line for product owners is worth keeping: AI is a powerful assistant but a poor navigator⁹. He also names the drift to watch, teams that adopt AI and quietly collaborate less, producing more output and worse outcomes⁹.

The reversal is this. Refinement looked like the most ceremonial, least necessary meeting in 2019. It is now the control that decides whether the speed you bought turns into throughput or into rework. Every slice you decline to take in refinement is a batch you will not have to review, integrate, and stabilize later, when changing it is far more expensive.

Adroit on the ground

One lesson from our own delivery pipeline belongs here, and it is a sizing lesson rather than a tooling one. Work we dispatch to autonomous agents has to be a vertical slice with an acceptance test an agent can actually run, because an agent cannot ask a clarifying question halfway through the job. The items that came back needing rework were the ones that looked small precisely because they were one architectural layer. The agent could not verify a change whose value lived in a layer it had not touched. The fix was structural. Every dispatched item had to cut through to observable behavior, and the slice boundary became the review boundary. What makes a story sprintable for a person is close to what makes it dispatchable to an agent: one clear outcome, one way to tell whether it happened.

What to run on Monday

Take the top ten items on your backlog and put each one through three questions.

• Does it fit the Small test? If your team can name the acceptance test and you could fit six to ten items of this size into a sprint, it passes. If not, keep cutting.
• Does done mean observable behavior? If finishing the item changes nothing a user could notice, it is a horizontal slice. Re-cut it.
• What is the sprint-threatening uncertainty? If there is one, resolve it before the item enters the sprint. If there is not, stop refining and let the team build.

Then fix the three failure modes in the order they usually appear. Layer-shaped stories get re-sliced vertically, and the six-to-ten rule becomes a gate rather than a wish. Refinement becomes a standing 30-minute session before each planning, owned by the product owner, with rotating attendance and the whole team pulled in only for items carrying real uncertainty²³. And the two symptoms get watched, carryover across sprint boundaries and the sprint goal hit rate, because they will tell you within a month whether the slicing is working².

The same discipline pays off downstream. A sliced backlog makes the front ceremony cheap, which is the argument in our companion piece on why sprint planning became a routing and review-budget decision. It makes forecasting honest, which is why velocity stopped predicting dates once AI split knowledge work into fast generation and slow validation. It makes the done contract enforceable, because a small slice can carry a real definition of done instead of a checklist nobody reads. It gives requirements somewhere to land, which is what changed when the requirements bottleneck moved upstream. And it gives the retro something actionable to work with, which is the theme of fixing the follow-through rather than the meeting.

The one-line version

A story that never fits a sprint is a slicing failure, not a team failure, and the fix is made in the thirty minutes before planning rather than in the retro after it. Size is decided, not discovered.