Vertical slicing — each slice delivering thin but complete user-facing value — versus horizontal slicing's feedback-delaying trap, worked through by splitting one real large story into 3-4 vertical slices.
Published September 23, 2026
A large story: "Users can filter and sort the product catalog"
Vertical slices (each one shippable, each delivering real user value):
Slice 1: filter by ONE criterion (category), no sort — ships, usable
Slice 2: add price-range filter — ships, adds value on top
Slice 3: add sort by price — ships, adds value on top
Slice 4: add multi-criteria combination (Composite pattern, from Search/Filter
Engine LLD) — ships, completes the original story
Each VERTICAL slice cuts all the way through the stack (UI, API, data) for a NARROW piece of functionality — it's genuinely usable and shippable on its own, even though it doesn't do everything the full story eventually will. This is the practical, day-to-day application of the same incremental-value thinking that underlies iterative software development generally: each slice is a real, working increment, not a partial, unusable fragment.
Horizontal slicing (the trap):
"Do all the backend filtering logic" (2 weeks) -> then "do all the frontend" (2 weeks)
-> NOTHING is demonstrable or shippable until BOTH layers are fully done
Horizontal slicing organizes work by TECHNICAL LAYER instead of user value — all backend work, then all frontend work. This feels natural (it matches how the codebase is structured) but has a real cost: nothing is genuinely testable or demonstrable until every layer is complete, which means feedback (from users, from stakeholders, from the team discovering a wrong assumption) arrives LATE, when it's more expensive to act on. Vertical slicing deliberately trades some layer-by-layer efficiency for much EARLIER feedback — a wrong assumption in Slice 1 gets caught after days, not after the entire multi-week horizontal effort is already built.
Taking one actual large story from a real backlog and forcing it into 3-4 vertical slices is a genuinely different skill than understanding the CONCEPT of vertical slicing — the real difficulty is usually in stories that DON'T obviously decompose (a complex migration, a foundational architecture change) where finding a genuinely thin-but-complete first slice takes real, deliberate thought. A useful forcing question: "what's the SMALLEST version of this that a real user could actually use and get value from, even if everything else is still missing?" — answering that question honestly is usually where Slice 1 comes from.
"Slice vertically" is the principle. In practice, it helps to have named ways of finding the slices. When a story is too big, try these in turn, and pick whichever produces the thinnest slice that still delivers something a user or stakeholder can see:
| Pattern | Split by… | Example: "Customers can pay for orders" |
|---|---|---|
| Workflow steps | Doing the steps of a process one at a time, or doing a simple end-to-end version first | 1) Pay by card with no saved cards. 2) Save a card. 3) Pay with a saved card |
| Business rule variations | The simple rule first, then the variations | 1) Flat shipping fee. 2) Free shipping over ₹999. 3) Regional rates |
| Data variations | One kind of input first | 1) Indian addresses. 2) International addresses |
| Interface variations | One channel or device first | 1) Web checkout. 2) Mobile app checkout |
| Happy path vs edge cases | The success path first, then failures | 1) Successful payment. 2) Declined card. 3) Timeout and retry |
| Operations (CRUD) | Create and read first, then update and delete | 1) Add an address. 2) Edit it. 3) Delete it |
| Performance or quality | Make it work, then make it fast or robust | 1) Search works on 10k products. 2) Sub-200 ms at 1M products |
| Spike | Learning first, when the real unknown is technical | 1) Timeboxed: can the payment provider's SDK do X? 2) Build it |
Two cautions:
The original story, "As a user, I can export all my account data", was estimated at three weeks, with unknowns about file formats, size and privacy review. Here's a split:
After slice 1, the riskiest architectural pieces (the async job, secure download links) are proven in production. Each later slice is small, and the product owner can reorder or drop slices 4 and 5 based on feedback. That flexibility is the real benefit of splitting well.
A quick checklist for each resulting story:
A slice that fails "Valuable" is usually a horizontal layer in disguise. A slice that fails "Estimable" usually needs a spike first.
Q: Is every large story genuinely sliceable vertically, or are some tasks inherently horizontal? A: Some genuinely foundational work (a database migration, a core authentication rewrite) resists clean vertical slicing since there's no meaningfully smaller 'usable' version of a half-migrated database — for this kind of work, the more honest answer is acknowledging it as necessarily horizontal, sequenced as its own distinct phase, rather than forcing an artificial vertical slice that doesn't actually deliver standalone value.
Q: Does vertical slicing conflict with the domain decomposition principles from the System Design track? A: No — they operate at different levels: Domain Decomposition is about SERVICE boundaries (a largely fixed, architectural decision); vertical slicing is about SEQUENCING WORK within (or across) those boundaries over time — a single vertical slice might touch multiple services, and that's fine, since the slicing concern here is about incremental DELIVERY, not service ownership.
Q: How small is 'too small' for a vertical slice? A: A slice that's SO thin it delivers no genuinely meaningful, standalone value (or that costs more in planning/review overhead than the actual work itself) has gone too far — the goal is the smallest slice that's still a real, coherent, valuable increment, not slicing purely for the sake of smallness.
Q: How does this connect to Handling Scope Creep, later in this chapter? A: Directly — a story that's been properly vertically sliced makes scope changes much easier to reason about and negotiate ('we can ship Slice 1 and 2 this sprint, and defer Slice 3's addition to next sprint') compared to a monolithic, horizontally-organized story where a mid-sprint addition has no clean seam to defer against without unraveling in-progress work.
Q: What's the quickest way to find a first vertical slice? A: Ask "what's the simplest version of this that a real user could use end to end?", then remove variations (other data types, channels, rules) and edge cases until what's left still works. Those removed pieces become the follow-up slices.
Q: When is a spike story appropriate? A: When the team can't estimate because of a technical unknown: an unfamiliar API, a performance question, a feasibility doubt. Timebox it, define the question it must answer, and follow it with real delivery stories sized using what was learned.
Q: How do you handle a story where every slice seems to need the whole backend first? A: Build the backend incrementally along with the first slice, only what that slice needs. If shared infrastructure is truly unavoidable, keep it minimal, and pair it with the first user-visible use in the same sprint, so it's validated immediately.