Slice vertically or drown
The teams I've seen struggle most with delivery have one thing in common: their backlogs are full of horizontal slices.
"Build the recipe page." "Implement the search feature." "Create the user dashboard." These sound like reasonable stories. They're not. They're traps.
How horizontal slicing kills momentum
Say you're building a recipe website. You create a story: "Build the recipe page." Seems simple. But that story needs ingredients, cooking steps, nutritional info, images, user comments. Each of those needs backend logic, database schemas, API endpoints. The recipe page needs the nutrition calculator. The nutrition calculator needs the ingredients structure. Everything depends on everything else.
Now every task blocks another task. Progress stalls. Standups become debates about what "done" means. The team loses momentum arguing about dependencies instead of shipping anything.
Vertical slicing
Instead of "build the recipe page," start with "display recipe title and description." Ship it. Then "add ingredients list." Ship it. Then "add cooking steps." Ship it.
Each slice cuts through all layers: UI, logic, data. Each one is complete on its own. Users can see something after every sprint. Feedback comes in early. Dependencies shrink because each piece stands alone.
Why we keep falling into the horizontal trap
It starts with good intentions. "Let's map the user journey." Front page, search page, recipe page. Three epics. Or: "We need database, backend, frontend, mobile." Four epics.
These breakdowns feel logical. They're also impossible to execute cleanly. Every epic needs most of the project's complexity upfront. You can't ship the frontend until the backend exists. You can't build search until you have recipes to search. Everything waits for everything else.
I've watched this happen in planning meetings. Time is short, requirements are fuzzy, so you default to big chunks. It feels like progress. It's actually a trap.
The fix
Stop slicing by technology. A feature isn't "frontend" or "backend." It's both, together, delivering something a user can touch.
Experienced teams drift toward vertical slicing naturally. Small wins feel better than slogging through endless epics. But it's easy to slip back into horizontal thinking when you're tired or rushed. You have to catch yourself.
This shows up in code too
The same debate exists in how we structure code. Horizontal: separate modules for UI, logic, data. Vertical: feature-rich components that own their whole stack. Modern frameworks lean vertical. TailwindCSS, component-centric architectures. Pete Hunt has a great talk on this if you want to go deeper.
The dinner party version
Think of it like hosting dinner. You could prepare everything, appetizers, main course, dessert, and only serve when it's all ready. Your guests would be starving by the time they ate.
Or you bring out the bruschetta while you're still working on the pasta. Guests eat. You get feedback. "More garlic next time." By the time dessert arrives, you've already adjusted based on how the earlier courses went.
That's vertical slicing. Each dish is complete. Each one delivers value. You're not waiting for the whole meal to be perfect before anyone gets fed.
How to tell if your slice is vertical
Ask: can this ship on its own? If it can't ship without another piece, it's not vertical.
"Display recipe title and description" can ship. Users see something. "Build recipe database schema" cannot ship on its own. Users see nothing until other work happens.
When you catch yourself creating stories that depend on other stories to deliver value, stop. Reslice.