How to break an epic into stories

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.

No. Epics carry the planned contribution to the outcome's target, and that is the number reported and validated. Tenhaw's founder co-led the design of the governance and reporting layer of a target operating model for 500 teams at HSBC Global Payment Solutions, piloted and due for global rollout in 2026. Rough per-story shares are still 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.

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.

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.

A vertical slice crosses the whole stack for one narrow piece of the user journey: data, logic, interface and whatever the user sees, releasable on its own. Stories called build the API or wire up the front end are really chapters, and a chapter belongs to a developer inside one story rather than on the board. The blunt test is whether you could release this alone and describe the difference to a customer in one sentence without mentioning another story. Split by layer and the value only appears when the last layer lands, which is why layer-sliced epics sit at ninety per cent complete for weeks with nothing shippable.

Set the ceiling from your own 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 that size at the refinement session. A story should be small enough to build inside a sprint and specific enough to test, and a giant story defeats forecasting because most of its risk sits in one lump nobody can size honestly. 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, and record the sizes, because that history feeds your p50 and p85 forecasts.

It writes a good first draft and a poor final one. 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 ten or so, because editing a draft beats an empty backlog. Then cut hard. 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, rewrite every criterion yourself, and expect to keep about half. Tenhaw checks model-written code the same way, against 72 handbook rules published on GitHub and enforced by an agent.

The thinnest 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. Rough value shares, written during sequencing and marked as not tracked, keep the choice honest, because they exist to say what gets built first and what a slip would cost. In the guide's worked example the thin first slice goes live in week two and produces a real signal three weeks before the epic finishes.

Criteria a tester, or a model, could disprove 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, and more than ten means 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, and state the assumptions the story carries. If a criterion contains intuitive, robust or seamless, it is a hope rather than a criterion, and nobody can fail it.

No. In an AI-native team the epic-level outcome ticket is the unit of work, and splitting it into stories out of habit strips out context the model needed and pre-empts judgement it can exercise itself, so you pay the decomposition cost and get slower delivery. The journey line becomes the key user journeys section of the outcome ticket, and the acceptance criteria become its test requirements, which must pass before the ticket is done. The thinking moves up a level rather than vanishing. Tenhaw's own two-week proof of concept for a London specialty insurance business ran on that footing, paired throughout with one of the client's engineers. Story splitting is for AI-augmented teams, where a developer writes the code and the model assists.

About half a day, plus the next two-weekly refinement session where the stories actually get sized. Inside that half day the journey map takes under an hour with the designer and one engineer, the rest goes on the AI-assisted first draft, the cutting, the sequencing and the acceptance criteria, and the approval gate runs as a forty-five minute working session with the whole set on screen. Sizing is the part you cannot do from a desk, because the ceiling comes from the team's own flow data rather than from opinion. Tenhaw publishes the whole method in full, so a team can run that half day itself without hiring anyone.

Four things, and fix any that are missing before you write a single story: the epic 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. 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 planned contribution at the top of whatever you are splitting on, because everything you produce gets checked back against that figure at the gate.

Yes, and it should take under an hour. Write the journey the epic touches, from the trigger to the moment value is realised, as a numbered line of plain-language steps, and six to twelve steps is normal. Do it with the designer and one engineer, on a whiteboard or in a shared doc, and mark which steps exist today and which this epic introduces or changes. That marking is what tells you where the work really is, because the steps the epic changes are the ones your stories have to account for. A step nobody can name is a step nobody has designed.

Product and engineering together, for forty-five minutes, with the whole set on screen. Run it as a working session rather than a signature. James Rooney chairs the first few of these gates on a Tenhaw engagement, then steps out once the team runs them itself. Product 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. The epic cannot leave Ready for Dev without both approvals and at least one product-approved story attached, and until it is approved none of its stories can start.

Tenhaw publishes one worked end to end. Northgate Home is an invented mid-market online retailer whose outcome is reducing mobile checkout abandonment, targeting £1.2m of recovered annual revenue across two quarters. One epic under it, guest checkout without account creation, carries a planned £400k and sits in Q3. The journey runs seven numbered steps and the epic changes steps three to five, which yields five stories: a guest pays by card on standard delivery, a guest chooses express delivery, a guest pays with either wallet method, a guest gets a confirmation and tracking email, and a guest is offered an account after payment rather than before.

You can say the number on the day it happens, which is why rough value shares get written at sequencing. In a worked £400k guest checkout epic the shares are £150k, £30k, £110k, £60k and £50k, so if the wallet story and the account-creation story slip out of Q3, the visible gap is £160k against a £400k epic. It surfaces at the next monthly outcome validation rather than as a surprise at roadmap close. Tenhaw holds itself to the same test of measurable value every month, and a month that delivers none is reported as a failed month. The trap is deferring the expensive slice and leaving the epic's planned contribution untouched, so it ships at a third of its number.

Give every story the numbers of the journey steps it covers, then read the set back against the numbered line rather than against your memory. The split is not finished until every step the epic changes has at least one story standing against it, and product runs exactly that check at the approval gate with the whole set on screen. It works only when the journey line is numbered and each story names its steps in writing. Without both, coverage becomes a show of hands. It is also the first line of the definition of done for a split, ahead of sizes and acceptance criteria.