Multi-currency is planned as schema, API, admin UI and customer UI tickets. What's wrong and how would you re-slice?

Horizontal slices deliver nothing usable until all are done, and hide integration and requirements risk. Re-slice vertically: e.g. EUR prices read-only for one country, then EUR checkout, refunds, a second currency with conversion rules, then admin tooling — with the riskiest part early.

Give three questions that help find a thinner slice.

What's the smallest version a real user could use? Which single case covers most users? What can be manual or read-only at first?

Why put the riskiest part of a project into an early slice?

Because the cost of learning that an assumption is wrong grows over time; testing it early (e.g. conversion rules) lets you change course before building the rest on top of it.

Slicing Work So It Ships — The Tech Lead Handbook

Scenario

Example team: the payments team plans "multi-currency support" as four tickets: database schema, backend API, admin UI, customer UI. Each takes weeks. After two months the schema and API are "done", nothing is usable, and product discovers that currency conversion rules differ by country.

What you see on the team

Large tickets that sit in progress for weeks.
"90% done" for a long time; integration problems found at the end.
No user feedback until everything is finished.
Demos that show database tables and API calls, not working features.

The common mistake

Splitting work horizontally by technical layer (database, backend, frontend) instead of vertically by user-visible capability.

Why it happens

Layers match how engineers think about the system and how teams are organised, so they feel natural. But a layer is not useful alone: value and feedback only appear when all layers work together, so horizontal slicing delays both until the end. Basecamp's Shape Up makes a related point: scope work into pieces that can be finished and integrated, rather than all-or-nothing projects.

The playbook

Slice by capability, thinly through all layers:

Multi-currency, sliced vertically
1. EUR prices shown for one product in one country (schema + API + UI, read only)
2. EUR checkout for card payments in that country
3. Refunds in EUR
4. Second currency (GBP), with conversion rule per country
5. Admin UI to manage prices per currency

Each slice is releasable (behind a flag if needed), testable end to end, and teaches you something.

Slice by risk first. Put the most uncertain part — here, conversion rules — in an early slice.

Good slicing questions:

What is the smallest version a real user could use?
Which case (one country, one payment method, one currency) covers most users?
What can be manual at first (admin via a script, not a UI)?
What can be read-only before it's editable?

Size check: a slice should take days, not weeks, for one or two people.

What to say

In refinement:

"Instead of schema, API and UI as separate tickets, what's the thinnest thing a customer could actually do with EUR? Let's start with one country and card payments only, and do the conversion rules in slice two — that's our biggest unknown."

Trade-offs

Thin slices may cause rework in lower layers as you learn; that rework is usually cheaper than building the wrong full layer.
Feature flags are needed to release incomplete capabilities; they need clean-up.
Some infrastructure work is genuinely horizontal (a new data store); keep it small and get to the first vertical slice quickly.

Signals it's working

Tickets finish in days; few items sit "in progress" for long.
Demos show working capabilities, however small.
Risky assumptions are tested in the first slices.
Product changes direction based on early slices — and that's fine.

Key points

Slice vertically through all layers by user-visible capability, not by technical layer.
Put the riskiest unknowns in the earliest slices.
Each slice should be releasable, testable end to end and take days, not weeks.
Start manual and read-only where possible; add admin and edit flows later.