Horizontal vs vertical slicing

Vertical slices ship value; horizontal slices ship promises. Why splitting by tech layer defers value, and how to slice by user outcome so something ships each sprint.

Vertical slicing splits a story along user outcomes; horizontal slicing splits it along technical layers. That single choice decides whether each slice ships something or nothing. Vertical slices ship value. Horizontal slices ship promises.

Horizontal slicing is splitting the way a knife splits dough — you get two halves of nothing.

The difference

Horizontal slicing splits along architectural layers: frontend this sprint, backend the next, database the sprint after. The work fits into sprints, but no single sprint produces anything users can touch. The team’s velocity numbers go up; the user-facing changelog stays empty.

Vertical slicing splits along user outcomes. A thin slice that touches every layer — a single button that actually works end to end, even if it only handles one input case. The team ships less per slice, but each slice is a real, shippable thing. The changelog fills up, users see progress, and the team can adjust course based on real usage rather than predicted usage.

A layered cake split horizontally versus the same cake split vertically Horizontal Vertical UI Logic Data → shipped nothing for users until all three land UI Logic Data slice 1 ships end-to-end, on its own sprint 1: nothing usable sprint 1: working slice
Horizontal slices ship one layer at a time. Vertical slices ship a working column — a little of every layer, usable now.

When horizontal slicing seems necessary

It usually isn’t. “We need the database schema before we can build the UI” is the classic justification, and it almost always gives way to “we can hard-code the response, ship the UI, and build the database in the next slice.” The discomfort of shipping a fake backend is real — but it’s smaller than the discomfort of shipping nothing for three sprints.

The exception: foundational platform work

Some infrastructure has no user-facing slice short of completion — migrating to a new auth provider, swapping a queue backend, replacing the deployment pipeline. These are projects, not stories. Treat them as such: don’t split them horizontally and pretend. Size them as a project, communicate the timeline, and accept that the team’s velocity will reflect the investment. Dressing a three-sprint migration up as three “stories” fools only the burndown chart.

If a slice doesn’t ship anything a user can use, it isn’t a slice.

Frequently asked questions

What is vertical slicing in agile?

Vertical slicing splits a story along user outcomes, so each slice is a thin cut through every layer — UI, logic, and data — that delivers something a user can actually use, even if it only handles one case. Each slice is releasable on its own.

What is the difference between horizontal and vertical slicing?

Horizontal slicing splits by technical layer — frontend one sprint, backend the next — so no single sprint produces anything a user can use. Vertical slicing splits by user outcome, so each slice ships a working end-to-end path. Vertical slices ship value; horizontal slices ship promises.

Why is vertical slicing better?

Because each slice is a real, shippable thing. The changelog fills up, users see progress, and the team can adjust course based on real usage rather than predicted usage. Horizontal slicing raises the velocity numbers while the user-facing product stays unchanged for sprints at a time.

When is horizontal slicing acceptable?

When the work is foundational platform work with no user-facing slice short of completion — migrating auth providers, swapping a queue backend, replacing the deploy pipeline. Those are projects, not stories: size them as such and communicate the timeline instead of pretending they split.