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.
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.