Decomposition looks like an administrative step: take the big thing, cut it into smaller things, put them in the backlog. It is actually the point where a team decides whether it will be able to deliver value incrementally or only at the end, and most teams make that decision without noticing.
The tell is in how the slices are made.
The two wrong cuts
Cutting by technical layer. Story one is the database schema, story two is the API, story three is the interface. Each is a comfortable unit of work and none of them can be released. The team completes two stories and has delivered nothing a user can do. Value arrives only when the last slice lands, which is exactly the risk profile incremental delivery exists to avoid.
Cutting by screen. Story one is the list page, story two is the detail page, story three is the edit modal. Better, but it still describes the solution rather than the need, and it locks the design before anyone has learned anything from shipping.
Both feel productive because they produce a tidy backlog. Tidiness is not the goal.
The cut that works: by outcome
Slice so that each story delivers a complete, if narrow, outcome for someone. Thin vertically rather than horizontally: a story goes through every layer it needs to, but serves one small case.
An epic like "customers can manage their subscriptions" slices badly into schema, API, and interface. It slices well into:
- A customer can see their current plan and renewal date. Read only, no changes. Ships alone, useful alone, and immediately reveals whether the data is actually available and correct.
- A customer can cancel. One action, the highest-anxiety path, and the one most likely to expose policy questions nobody has answered.
- A customer can upgrade. Introduces billing, proration, and effective dates. Genuinely separate problem from cancelling.
- A customer can downgrade at period end. Different rules from upgrade, often deferred, frequently forgotten until late.
Each of those could be released on its own and would be worth something. That is the test.
Ask what the smallest thing is that would let one real user do one useful thing end to end. Then ask what you could remove from it and still have that be true. The answer is usually your first story.
Where to look for natural seams
Epics have joints. These are the ones that show up most often.
- By user type. Administrator first, standard user later, or the reverse. Different rules, genuinely different work.
- By data variation. One currency before many. One region before all. Domestic before international.
- By workflow step. Submit before approve before archive, when each has value on its own.
- By rule complexity. The simple case first, the seventeen exceptions later, once the simple case has proven the shape.
- By interface depth. Functional but plain first, refined later, when learning from real use is worth more than polish.
- By happy path then edge cases. Legitimate, but only when the edge cases are genuinely rare, otherwise you are deferring the hard part and calling it progress.
How small is small enough
Two practical limits, and neither is a points value.
A story is too big if it cannot be finished within one iteration, because unfinished work carries no information: it neither validates nor invalidates anything.
A story is too small if it cannot be described as delivering something to someone. "Add an index to the orders table" is a task, and forcing it into user story shape produces the well-known parody format that helps nobody. Tasks are fine. They just are not stories, and pretending otherwise makes the backlog harder to prioritise.
Key takeaways
- Slice vertically by outcome, not horizontally by layer or by screen.
- Each story should be releasable on its own and worth something on its own.
- The right seams are usually user type, data variation, workflow step, or rule complexity.
- A story too big to finish in an iteration carries no information until it is done.
Decomposition is where requirement quality is decided
A vague epic produces vague stories, and the vagueness multiplies rather than dividing. If the epic does not state the outcome or the rules, each story inherits the gap, and now you have six ambiguous items instead of one.
So the useful sequence is: get the epic clear enough that its acceptance is describable, then slice. Slicing first and hoping the detail arrives later is how teams end up with a backlog of forty items that all need a conversation before anyone can start.