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 short answer: break an epic down by outcome, not by layer or screen. Each user story should let one kind of user do one useful thing end to end, be small enough to finish in an iteration, and carry its own testable acceptance criteria. From a PRD, find the features first, clarify each one, then slice each feature into stories.
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.
Story splitting examples
| Too big | Split into | Seam used |
|---|---|---|
| Customers can get refunds | A refund within the window, to the original card; refunds above a threshold go to an agent for approval; partial refunds | Rule complexity |
| Customers and support agents can manage orders | Customers can view and cancel their own orders; support agents can amend any order | User type |
| Checkout supports every currency | Checkout in one currency; additional currencies with conversion | Data variation |
| Employees can claim expenses | Submit a claim; a manager approves or rejects it; approved claims are archived | Workflow step |
Each row's first slice can be released on its own. If yours cannot, the seam is in the wrong place.
From a PRD or requirements document to user stories
A product requirements document is usually organised by section, not by outcome, so it does not slice directly into stories. Work in this order:
- Read for outcomes, not sections. List what each type of user will be able to do that they cannot do today.
- Group outcomes into features. A feature is a capability with its own actors, rules and acceptance, that can be prioritised and deferred independently of the others.
- Record priority and dependencies. Which features must come first, and which cannot work without another.
- Clarify each feature before slicing it. State its rules, failure behaviour and acceptance; gaps found now are cheaper than gaps found in six stories later.
- Slice each feature into stories using the seams above.
- Give each story testable acceptance criteria. See acceptance criteria examples and a template.
In ReqLens, the first steps are supported directly. Upload the document on the Decomposition screen, and ReqLens breaks it into features, each with a purpose, priority, dependencies and complexity, then checks the boundaries between them. Each feature is then elaborated in Requirement Studio, which is where its acceptance criteria are attached. ReqLens does not write user stories: slicing features into stories stays with your team, using the method on this page. See how ReqLens breaks a requirement into features, and where document uploads fit in requirements gathering.
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.
- From a PRD, find and clarify features first, then slice each feature into stories with their own criteria.
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. Each story then needs its own testable criteria: see acceptance criteria examples and a reusable template.