Horizontal vs vertical slicing

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

Horizontal slicing splits along architectural layers: frontend this sprint, backend the next, database the sprint after. The work fits in sprints, but neither sprint produces anything users can use. The team's velocity numbers go up; the user-facing change-log 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 change-log fills up, users see progress, and the team can adjust course based on real usage rather than predicted usage.

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.

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

See SPIDR for the five reliable vertical-slicing cuts; other splitting patterns for the rest of the toolkit.