How to break an epic into stories
A story is the smallest piece of user-visible value the team can ship. If it does not change the user's experience, it is a chapter, not a story.
- steps
- 9
- named failure modes
- 5
- definition-of-done criteria
- 6
How to break an epic into stories, in one paragraph
Breaking an epic into stories is where a priced piece of a business outcome becomes work a team can start on Monday. A story is the smallest piece of user-visible value you can ship: small enough to build inside a sprint, specific enough to test, traceable to one epic and one outcome. Good looks like four to eight stories that between them cover every journey step the epic changes, each releasable on its own, each sized against your own flow data, with at least one product-approved so the epic can leave Ready for Dev.
What these are. The delivery operating model our engagements install alongside client teams: the method underneath the agentic work rather than the agentic work itself, published in full and free to use. It is written for the person running a quarter, not for a buyer, so if you are evaluating us, read the five priced engagements or the case studies instead.
Do this once an epic has a parent outcome, a planned currency contribution and a quarter on the roadmap, and before it can leave Ready for Dev. If your team runs AI-native, skip it: the epic-level outcome ticket is the unit of work.
- Time to run it once
- About half a day, plus a refinement session
- What you need
- A whiteboard or shared document for the journey map
- Your team's flow data, for the size ceiling
- The delivery tracker
Step by step
Each step is deep-linkable, so you can send a colleague the one that is in dispute.
- 1
Check the epic is fit to split
Open the epic and confirm four things before you write a single story: it links to exactly one outcome, it carries a planned currency contribution to that outcome's target, it belongs to one quarter's roadmap, and it has been through research and design rather than sitting in idea. Fix anything missing now. Splitting an epic with no number attached produces stories nobody can prioritise, and splitting one with no quarter produces work that quietly rolls forward. Write the epic's planned contribution at the top of whatever you are splitting on. Everything you produce gets checked back against that figure at the gate.
- 2
Map the journey before you slice
Write the user journey the epic touches, from the trigger to the moment value is realised, as a numbered line of plain-language steps.
Six to twelve steps is normal. Do it with the designer and one engineer, on a whiteboard or in a shared doc, in under an hour. Mark which steps exist today and which this epic introduces or changes. Keep the numbers, because every story should name the steps it covers, and that is what turns coverage into something you can check rather than something you feel. A step nobody can name is a step nobody has designed.
- 3
Draft with AI, then cut it hard
Paste the outcome, the epic, its currency contribution and the numbered journey into a model, and ask for candidate stories with acceptance criteria and the journey steps each one covers. Ask for more than you need, ten or so, because editing a draft beats staring at an empty backlog. Then cut. Models duplicate slices, write one story per screen rather than per journey step, and produce criteria that restate the title. Delete anything that does not change what a user can do, merge anything that cannot ship alone, and rewrite every criterion in your own words. Expect to keep about half.
- 4
Slice vertically, never by layer
Every story crosses the whole stack for a narrow piece of journey: data, logic, interface, and whatever the user sees.
Refuse stories called build the API, add the database table or wire up the front end. Those are chapters, and they belong to a developer inside one story rather than on your board. The test is blunt: could you release this alone, and describe the difference to a customer in one sentence without mentioning another story? If not, you have sliced by layer or by team, and the epic will sit at ninety per cent complete for weeks with nothing shippable.
- 5
Size against your flow data, split above ceiling
Take each candidate to the two-weekly refinement session and size it.
Set the ceiling from your flow data rather than from opinion: look at the stories your team finished last quarter, find the size at which cycle times start to scatter, and split anything at or above it. Five splits are worth knowing: by journey step, by business rule, by data variation, by interface, and happy path first with the exceptions following. Prefer happy path first. Record the sizes rather than arguing about them, because that record feeds your p50 and p85 forecasts. A story nobody can size is discovery, and it goes back to research.
- 6
Sequence so the first slice ships alone
Order the set so the first story is a thin path through the whole journey that a real user could complete, even if it handles one case for one segment. It has to build without any other story in the set, and it should touch the measure the outcome is judged on, so live monitoring gets a signal early. Everything after it thickens the path. While you sequence, write a rough value share against each story, marked as not tracked: the model prices epics, not stories, and these numbers exist to say what gets built first and what a slip would cost.
- 7
Write acceptance criteria you can fail
Each story needs criteria specific enough that a tester, or a model, could disprove them without asking you a question.
Write observable behaviour: given this state, when the user does this, then this happens. Three to seven per story is normal. If you need more than ten, you are describing two stories, so go back and split. Include the negative cases you care about and name the ones you have decided to ignore, because an unnamed exclusion turns into a defect argument later. State the assumptions the story carries. If a criterion contains intuitive, robust or seamless, it is a hope, not a criterion.
- 8
Clear the approval gate deliberately
The epic cannot leave Ready for Dev without product approval, engineering approval and at least one product-approved story attached.
Run it as a forty-five minute working session with the whole set on screen, not a signature. Product confirms the stories cover every journey step the epic changes, sums the rough value shares against the epic's planned contribution, and agrees the first story is the right first one. Engineering confirms each slice is buildable as written and flags any that hides a dependency on another team. Stage the rest of the set if you like: until the epic is product-approved, none of its stories can start.
- 9
Route everything that is not a story
A split always throws off work that is not user-visible value, and each kind has a home.
Work a developer discovers mid-build becomes a chapter under the story it belongs to. Defects in something already shipped go to the quarter's Bug Budget epic and never into this epic's list, or the epic's burn-down quietly swallows your quality signal. Refactoring and platform work this epic depends on goes to the Tech Debt epic and gets sequenced against it. If a piece of work fits none of those, it belongs to a different outcome, and the honest move is to raise it there.
Worked example: a £400k epic under a £1.2m outcome
Northgate Home is an invented mid-market online retailer. Its outcome is reduce checkout abandonment on mobile, target £1.2m of recovered annual revenue, spanning two quarters. One epic under it is guest checkout without account creation, planned contribution £400k, sitting in Q3. The journey line runs seven steps: land on basket, choose checkout, enter delivery address, choose delivery option, pay, confirm, receive confirmation email. Steps three to five are what this epic changes. The split produces five stories. One, a guest completes a card payment on standard delivery to a UK address, sized 8. Two, a guest chooses express delivery, sized 3. Three, a guest pays with either of the two wallet methods, sized 5. Four, a guest receives an order confirmation and tracking email without an account, sized 3. Five, a guest is offered account creation after payment rather than before, sized 5. Story one is the thin path: it goes live in week two and produces a real abandonment signal three weeks before the epic finishes. The rough value shares are £150k on story one, £30k on two, £110k on three, £60k on four and £50k on five, summing to the epic's £400k. They are a sequencing tool rather than commitments, because the model prices epics and not stories. They say story one carries most of the money and gets built first, and that if stories three and five slip out of Q3 the visible gap is £160k against a £400k epic. That is a conversation at the next monthly outcome validation rather than a surprise at roadmap close.
Where this goes wrong
- 01
Stories sliced by layer or by team.
It happens because the slices mirror the org chart and because layer-sized estimates feel easier to give. The result is an epic stuck at ninety per cent for a month with nothing released, because the value only appears when the last layer lands.
- 02
Scope leaking out during the split.
The expensive slice gets deferred to next quarter, nobody restates the epic's planned contribution, and the epic ships at a third of its number while the outcome still shows the full target. Sum the shares at the approval gate, not at value monitoring.
- 03
One giant first story with a queue of tidy-up behind it.
Usually a sign the team wanted to start rather than to slice. It defeats forecasting, because most of the epic's risk sits in one lump nobody could size honestly.
- 04
Acceptance criteria written after the code.
They describe what was built rather than what was needed, and product approval at release becomes a formality. Write them before the story leaves the backlog.
- 05
Splitting an AI-native team's epic into stories out of habit.
It strips out the surrounding context the model needed and pre-empts judgement the model can exercise itself, so you pay the decomposition cost and get slower delivery for it. Put the journeys and the test requirements in the outcome ticket instead.
Done means
- Every numbered journey step the epic changes is covered by at least one story, and every story names the steps it covers.
- Every story is a vertical slice you could release on its own and describe to a customer in one sentence.
- Every story is sized, and nothing sits at or above the ceiling your flow data sets.
- Every story has acceptance criteria written as observable behaviour, with the negative cases you care about named and the ones you are ignoring stated.
- The rough value shares sum to the epic's planned contribution, or the difference is written down and the epic's number restated.
- The epic has product approval, engineering approval and at least one product-approved story, and the team agrees which story is built first.
For an AI-augmented team this guide runs as written, with the model producing the first-draft split and a human cutting it back. An AI-native team does not do it at all: the epic-level outcome ticket is the unit of work, and decomposing below it strips out the context the model needed. The thinking does not disappear though, it moves up a level. The journey line becomes the key user journeys section of the outcome ticket, and the acceptance criteria become its test requirements, which is what has to pass before the ticket is done.
The two delivery modes, side by side →Questions
How many stories should an epic have?
There is no fixed number, but four to eight is the usual landing point for an epic that fits one quarter. One story means either a small epic, which is fine, or that you have not sliced. More than about twelve usually means the epic was two epics wearing one number, and the honest fix is to split the epic and divide its planned contribution rather than carry a backlog nobody can hold in their head.
Do stories carry a currency value?
No. Epics carry the planned contribution to the outcome's target, and that is the number reported and validated. Rough per-story shares are worth writing during sequencing because they tell you what to build first and what a slip costs, but they are not tracked, not reported and not something anyone is held to. If per-story figures start appearing in status reports you have created a second set of numbers that will disagree with the first.
What do I do with a story nobody can size?
Treat it as discovery, not as a story. If refinement cannot size it because the team does not understand the problem, the shape of the data or what the user needs, send it back to the research phase with a specific question attached and a date you need the answer by. Sizing it anyway produces a number with no information in it, and that number then pollutes the p50 and p85 forecasts everyone is planning against.
Can I write stories before the epic is approved?
Yes, and staging the whole set in advance is often the point of the working session. What you cannot do is start them. A story cannot leave the backlog until its parent epic is product-approved, and the epic cannot leave Ready for Dev without product approval, engineering approval and at least one product-approved story attached. So the set can exist, sized and sequenced, waiting on the gate.
More on setting up the work
These guides are written to be read in order.
05How to do discovery research
Discovery is how a hypothesis stops being a hunch. Keep the evidence linked to the work, not buried in an archive.
How to set an outcome
An outcome is a business result with a price tag. If you cannot price it, it is not an outcome, it is a wish.
How to put together a quarterly roadmap
A roadmap is one quarter, twelve to thirteen weeks. Outcomes can span quarters; epics cannot.
How to write a value-focused epic
An epic is your unit of value contribution to an outcome. If it does not carry a number, it is a feature wishlist.
Want help installing this?
These guides are free and you owe us nothing for using them. If you would rather have operators install the operating model alongside your teams and stay until it sticks, that is what our engagements do.
Most organisations start with a fixed-price Agent-Readiness Audit · £30k–£90k · 6–8 weeks