Story Slicing Patterns

---

Why Slicing Patterns Exist

Smallness is the single most reliable predictor of agile delivery health.¹ Small stories ship faster, get feedback earlier, integrate cleaner, and produce throughput that is easier to forecast. Yet most teams find slicing hard — not because they disagree with the principle, but because they run out of moves. A two-week story stares back at them and they cannot see a seam.

Story slicing patterns are the catalog of named moves that close that gap. SPIDR provides a memorable starter kit; the broader pattern library — assembled most notably by Richard Lawrence, Christiaan Verwijs, and Humanizing Work — extends it with the additional moves that handle harder cases.²

The Vertical Slice Principle

Every healthy slice shares one property: it cuts vertically through the system, from the user-facing surface down to the data store, delivering something a user could in principle observe. Horizontal slices — "build the database," "build the API," "build the UI" — fail INVEST's Value criterion. They are necessary work but they are not standalone stories.

The diagram every coach draws on a whiteboard: a wedding cake with frosting (UI), filling (business logic), and base (data). A vertical slice is a thin wedge through all three. A horizontal slice is one whole layer of cake with no other layers — technically a lot of work, but no one would call it a slice of cake.

The Pattern Catalog

Workflow steps

Cut the story along the steps of the workflow it implements. A checkout story splits into “view cart”, “enter shipping”, “enter payment”, “confirm order”. Each step delivers a coherent piece of the journey.

Business rule variations

Identify the rules that apply and ship them one at a time. Apply standard tax first; apply discounted tax for charities next; apply complex VAT logic for cross-border orders last.

Happy path / unhappy path

Ship the success case first; defer error handling, edge cases, and recovery flows. This is one of the most frequent and useful splits, particularly under deadline pressure.

Input variation

Restrict the inputs the story accepts. Support import from CSV first; then XLSX, then JSON. Handle US phone numbers; international next sprint.

Data variation

Restrict the kinds of data the story handles. Process retail orders first; wholesale orders with their different pricing model later.

Interface variation

Deliver the capability through one interface first, then add others. Admin can perform action via API; UI for the same action is a separate story.

Defer performance

Make it work first; make it fast later. Synchronous CSV export; async export with email notification as a follow-up.

Operations (CRUD splits)

Treat Create, Read, Update, and Delete as separate stories. Often you need only Create and Read to deliver useful value; Update and Delete can follow.

Spike

When the unknowns are too large to estimate at all, split off a time-boxed investigation. See the SPIDR article for guidance.

Major effort first

Split off the part that contains the bulk of the work or risk and ship it first. The remainder becomes cheaper and more predictable.

Simple, then enhance

Build the simplest possible implementation first — even if it's ugly or limited — and enhance in subsequent stories. Static dropdown of countries; dynamic auto-complete next.

Choosing a Slice

The catalog has more moves than any one story needs. The skill is in choosing which slice delivers the most valuable thin wedge first. Three useful questions:

• Which slice could we ship to a real user this week?
• Which slice would teach us the most about whether the rest is worth building?
• Which slice carries the most risk we should de-risk first?

Different stories will favor different questions. A new product bet leans on the second. A well-understood feature with a deadline leans on the first. A technically ambitious project leans on the third.

Patterns to Avoid

• Layered slices. Database story, then API story, then UI story. Not vertical. Not independently valuable.
• Task-level slices. "Set up routing," "build the form component." These are tasks, not stories.
• "Configurable later" slices. Stories whose value is "the user can change this in a settings panel we haven't built yet." The future configurability is not a slice of value.
• "Spike then build" as the only plan. Spikes are useful, but a backlog of spikes is a research project. Pair every spike with the next concrete slice.

Coaching Tips

Run a slicing workshop.

One hour. Pick a real big story. Walk the catalog. The patterns transfer fastest through hands-on practice.

Track average story size monthly.

If the median story isn't shrinking over time, the slicing habit hasn't stuck. Open a retro item.

Catch horizontal slices early.

"Database for X" / "API for X" / "UI for X" is the most common anti-pattern. Re-slice as soon as you see it.

Apply the "could you ship this?" test.

If the PO would not actually ship the slice on its own, it's not a slice. Re-cut.

Don't slice into oblivion.

There is a point past which further slicing produces overhead, not value. A small handful of slices is usually right.

Pair slicing with WIP limits.

Smaller stories enable lower WIP — and lower WIP makes smaller stories worth doing. The disciplines reinforce each other.

Summary

Story slicing is the single most leveraged technical skill in agile story crafting. The patterns are not a method — they are vocabulary. Teams that learn the catalog stop getting stuck. They argue less about whether a story can be split and more about which split is best. That shift, repeated across hundreds of stories, is what produces the small, predictable flow that healthy delivery feels like.

Back to Story Crafting