Agile · Lesson 01

The Vertical Slice

Everything else in agile is a way of managing small batches. This lesson is about making the batches small — the one skill that still pays when you are the only person on the team.

The win By the end of this page you will have taken one real thing you are building and cut it into four or more pieces, each of which you could finish in a day and actually use. Not four tasks. Four working things.

Why this first

You have no Scrum Master, no sprint review, no stakeholder to demo to. Almost every agile practice is a mechanism for getting feedback out of other people — and at a team of one, most of them quietly stop working.

Small batches don't. They work because the feedback isn't social, it's structural: a thing either runs or it doesn't. The Agile Manifesto's first principle is "early and continuous delivery of valuable software", and its seventh is that "working software is the primary measure of progress" 12 Principles. Solo, those two are the whole game. The rest is scaffolding for coordinating humans you don't have.

So the question is only ever: how small can the next working thing be?

Vertical, not horizontal

Take a feature — say, letting people sign in. There are two ways to cut it.

Horizontal — layer at a time

interface — all of it

logic

data

One layer finished. Nothing works. Nothing to try, nothing to show, nothing learned.

Vertical — thin slice, all layers

formresetOAuth

checktokenlink

userscodesproviders

One narrow column finished. You can log in. Everything after this is an improvement to a working system.

Bill Wake put the rule in one line back in 2003: when splitting, "slice vertically through technical layers rather than horizontally to preserve customer value" INVEST. Alistair Cockburn's version is blunter — "all of the slicing decisions are based on the business situation, not the technology aspects" Elephant Carpaccio.

The solo failure mode Horizontal slicing feels more efficient when you're alone — you're in the database, so you may as well do all the tables. That's the trap. Batching by layer means the first moment you find out the design is wrong is the moment all three layers are built. Every hour of that work was a bet placed before any evidence came in.

A worked cut

Feature: "users can sign in". Most people see two or three pieces. Here are six, in the order you'd build them, each one usable the moment it lands:

#	Slice	Working at the end of it
1	Email + password, one hardcoded user, no storage	You can get past the door.
2	Real users table, hashed passwords, sign-up form	Other people can get in.
3	Session persists across reloads	Login means something.
4	Wrong-password and duplicate-email errors	It survives contact with users.
5	Password reset by emailed link	You stop doing support by hand.
6	Google sign-in as an alternative	Signup friction drops.

Notice what slice 1 does: it is obviously incomplete, and it is still the most valuable hour of the six, because everything after it is now an edit to running code rather than a guess. And notice that slices 5 and 6 are droppable — you could ship without them and find out whether anyone asks. That droppability is the tell that the cut was made in the right place.

Nine patterns, one card When it isn't obvious where to cut, you don't improvise — you run down a list. The nine standard splitting patterns live on the splitting patterns reference card. The cut above used simple/complex (1), major effort (2), business rule variations (4) and workflow steps (5). Keep that card open for the exercise below.

Check yourself

Answer from memory. Getting one wrong here is worth more than getting it right by scrolling back up.

Now do it to your own work

This is the part that matters. Pick one real thing you intend to build in the next two weeks — the fuzzier and larger the better. Write it at the top of a page.

Step 1 — cut it into four pieces. Try before opening.

Run the card top-down: workflow steps → CRUD → business rules → data variations → entry methods → major effort → simple/complex → performance. Stop at the first pattern that fits. Don't search for the best one; the first one that fits is nearly always good enough, and hunting for elegance is how slicing turns into an afternoon of planning.

If nothing fits, your feature is probably two features. Write both down and cut them separately.

Step 2 — apply the four tests to your cut

Throwaway: could you bin one piece and still have something worth shipping? If not, cut again.
Vertical: does each piece leave something you can look at and use?
Balance: roughly equal sizes? A 5-3 split usually means the 5 is hiding another story.
Testable: one sentence per piece saying how you'd know it's done.

Step 3 — the real test

Look at piece #1. Could you finish it today?

If no, it is still too big — cut that one piece again with a second pattern. Slices compose: a workflow-step split of a CRUD split is completely normal, and this is exactly how Cockburn's workshop gets to 15–20 pieces where people first saw three.

If yes: build it today. That is the whole lesson. Everything in the rest of this course — WIP limits, cycle time, sprints, appetite — is bookkeeping on top of a stream of finished slices. Without the slices there is nothing to keep books on.

Did it work? Tell your teacher what you cut and how the pieces came out. Slicing is judged, not calculated — a second pair of eyes on your first three or four real cuts is worth more than reading another article about it.

Read this next

Primary source: The Humanizing Work Guide to Splitting User Stories — Richard Lawrence & Peter Green. Twenty minutes, and the most practical page written on this topic. It has the flowchart the reference card compresses, plus worked examples for each of the nine patterns.

If you want the drill: The Elephant Carpaccio facilitation guide — designed for groups, but the exercise (build a retail calculator in 15–20 demoable slices, five rounds of eight minutes) runs fine alone and is the sharpest deliberate practice available for this skill.