How to Break Down an Epic Into User Stories

Break an epic down by slicing it vertically: every story should deliver something a person can do end to end, however narrow that thing is. Split by workflow step, user role, business rule, or happy path versus edge case. Never by layer. Most epics settle at three to ten stories.

This is for product managers, business analysts and tech leads who keep producing stories that cannot be demonstrated, or epics that stay open for two quarters. It covers the splitting patterns worth knowing, a worked example, how big a story should be, and the point where splitting stops helping.

How do you break down an epic into stories?

Start from the outcome and cut the thinnest slice that still reaches the user, then split what remains. The order matters, because teams that begin with a list of tasks end up with a list of tasks.

1. Write the epic’s outcome in one sentence, and name who gets it. If you cannot say who is better off, you have a project, not an epic.
2. List the steps that person takes to reach the outcome. This is usually the first and best split, and it takes ten minutes.
3. Cut the first slice end to end. One user, one path, no options, behind a flag if needed. This slice exists to test whether the shape of the epic is right.
4. Split the remainder using the patterns below. Work through the list rather than inventing splits from scratch, because the patterns catch slices you will otherwise miss.
5. Check each slice against INVEST. Bill Wake’s acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) is thirty years old and still the fastest filter. Independent and testable are where most splits fail.
6. Write acceptance criteria for the first two or three only. Detail on story eight is waste, because story three will change your mind about it. Acceptance criteria formats and how they differ from a definition of ready covers the shapes that survive review.
7. Record what you decided not to build. Rejected slices are the cheapest scope protection you will ever write down.

Splitting is a conversation, and it goes wrong when one person does it alone the night before refinement. Teams that keep landing there sometimes give the conversation a structure: Projan takes the split as a Slack discussion, asking which slice a user could use on its own and what done looks like for each, then writes the agreed stories out to Jira or Linear. What matters is that the engineer who will hit the integration problem is in the room while the slices are being drawn.

Which splitting patterns actually work?

Use a known pattern list rather than improvising, because the same handful of splits covers most epics. Richard Lawrence’s story splitting patterns and Mike Cohn’s SPIDR (Spikes, Paths, Interfaces, Data, Rules) are the two sets most teams work from, and they overlap heavily.

Pattern	Split by	Example slice
Workflow steps	Stages in the user’s journey	Submit a request, then approve one, then report on them
User roles	Who is doing it	Customer first, support agent later, finance last
Business rules	Conditions the system applies	Standard items now, restricted and hazardous items next
Happy path and edge cases	Success first, failure handling after	Card payment succeeds, then declines and retries
Data variations	Types, formats, volumes	One currency now, multi-currency later
Operations	Create, read, update, delete	View existing records before editing them
Interface or platform	Where it is used	Web first, mobile after, API for partners last
Spike	Unknowns	Timeboxed investigation of the address lookup provider

The pattern that gets misused is the layer split: one story for the database, one for the API, one for the front end. Splitting by layer is not splitting. It is scheduling the same story three times, and it produces a sprint where everything is in progress and nothing is finished. The test is simple. If a slice cannot be shown to somebody outside the team, it is a task inside a story, not a story. The boundary between the two is worth getting straight, and epic vs user story vs task sets it out properly.

What is an example of an epic story?

Here is an epic and its children, split by workflow step and then by role. The epic: customers can return an online order without contacting support.

• See what is returnable. As a customer, I can see which items on a past order are eligible for return and why the others are not. Read-only, no return can be started yet. This slice proves the eligibility rules are right before anything depends on them.
• Request one return. As a customer, I can request a return for a single eligible item and receive a confirmation email. One item, standard reason codes, no label.
• Get a label. As a customer, I can download a returns label from the confirmation screen.
• Handle the awkward cases. As a customer, I am told clearly when an item is outside the return window, and offered the support contact route instead.
• Support can intervene. As a support agent, I can view and cancel an in-flight return request so a customer who changes their mind does not have to wait for it to expire.
• Multiple items at once. As a customer, I can return several items from one order in a single request.

Six stories, each demonstrable, each shippable in some order. Note what is absent: there is no “build the returns service” story and no “design the returns screens” story. Both would be real work and neither would be a story, because neither can be released or judged on its own.

Note also the sequencing logic. The first slice is the one that answers the riskiest question, which here is whether the eligibility rules match what the returns policy actually says. Epics rarely fail because they were too big. They fail because nobody agreed what the first slice was, so three people started three different halves.

How big should a user story be?

A story should be finishable by the team inside one sprint with room left over, which in practice means a few days of work rather than most of a fortnight. Anything that consumes half a two-week sprint on its own is a risk, because it leaves no space for the thing you discover on day four.

Practical ceilings teams use, none of them canonical:

• Sprint fit is the hard rule. If it cannot finish inside a sprint, it has to be split. This is the only sizing rule that is genuinely universal.
• Estimate ceilings are common. Plenty of teams cap stories at eight points on a modified Fibonacci scale and split anything larger by default. The number is arbitrary; the habit of splitting on a trigger is not.
• Three to five days of one pair’s work is a comfortable upper limit for most teams doing continuous delivery.
• Count the people, not just the hours. A story that needs three specialists in sequence is too big even when the total effort is small, because the handoffs are where it will sit idle.

The lower bound gets less attention and causes as much trouble. A story that can only be demonstrated by opening a database client is not a story. Stories smaller than a day tend to be tasks that were promoted to make a board look busy, and they add ceremony without adding clarity. Getting the wording right at either size is its own skill, covered in user stories, use cases and tickets.

Size is also relative to the team. A story that is two days for a team that owns the whole stack is two weeks for a team that has to raise a ticket with a platform group. Split for the team that will actually pick it up.

How many stories should an epic have?

There is no canonical number, and any source giving you one has made it up. The useful range in practice is three to ten, for reasons that are about attention rather than arithmetic.

• Fewer than three stories and the epic is doing no work. Either it is a story with subtasks, or the split is horizontal and the pieces are not independently releasable.
• Three to ten is where an epic stays comprehensible. Everyone can hold the shape of it in their head, and it can plausibly finish within a quarter.
• More than about fifteen and you have a theme or an initiative. Break it into several epics with distinct outcomes, otherwise progress becomes unreadable and the epic burns down at a rate nobody can interpret.

Watch out for the epic that grows during delivery. New stories arriving mid-flight are normal; new stories arriving that do not serve the original outcome statement are how a six-week epic becomes a permanent fixture. Check every addition against the outcome sentence. If it does not serve that sentence, it belongs somewhere else, even when it is genuinely worth doing.

How do you convert an epic to a story?

Change the issue type, but only after you have established that it really is a story. The question comes up in two different situations and they need different answers.

The first is the tracker mechanic. In Jira, Linear and most other tools you change an issue’s type in place, through the issue type field or a move action depending on your version. The catch is hierarchy: a story cannot parent other stories, so you must reparent or delete the children first, and you will usually lose the epic-level fields such as colour and epic name. Do it in that order and the conversion is clean. Do it in the other order and you will spend an afternoon hunting orphaned tickets. If you are rearranging hierarchy often, how to structure a Jira backlog is worth reading first.

The second situation is the judgement call, and it is the one that matters. An epic should become a story when it turns out to describe a single releasable change: one user, one path, finishable in a sprint. This happens more than teams admit, usually because the work was sized during roadmap planning when it looked frightening, and refinement revealed it was a fortnight of work behind a flag. Demote it without ceremony. Carrying a one-story epic clutters the board and inflates every report that counts epics.

When splitting has gone too far

Stop splitting when the coordination costs more than the work. Slicing is a tool for reducing risk and getting feedback earlier, not a scoring system, and past a certain point it inverts.

Signs you have overshot:

• Stories that cannot be released individually, so they are all held for a big-bang deploy anyway
• A dependency chain where story four cannot start until stories one to three are all done, which means you have written one story in four tickets
• Refinement sessions spent debating ticket boundaries rather than the behaviour the user gets
• Acceptance criteria that describe internal state because there is no observable outcome left to describe
• Splits made to fit a points target rather than to reduce uncertainty

The honest check is to ask what you would learn from shipping each slice alone. If the answer for three consecutive stories is “nothing, they only make sense together”, merge them and accept the larger story. A single story that takes eight days and teaches you something beats four two-day stories that teach you nothing until the last one lands. Refinement is where this gets caught, so raise it there rather than in sprint planning, when the tickets already exist and nobody wants to touch them.

Frequently asked questions

How to break down epics into stories? Do it with the team, in refinement, on the two or three epics closest to the top of the backlog. One person splitting alone produces slices that look tidy and hide the integration work. Timebox it to about half an hour per epic, take the first three slices to acceptance criteria, and leave the rest as titles until they get closer.

Can an epic have multiple user stories? Yes. That is what an epic is for. An epic is a container for stories that share an outcome, and one with a single child is not doing any work. The reverse is not true in most trackers: a story sits under one epic only, so shared work either belongs to one of them or becomes its own story.

How small should a user story be? Small enough to finish inside a sprint with room to spare, and large enough to demonstrate. The lower bound matters more than teams think. If the only way to show the result is to open a database client or read a log, you have written a task, and it belongs inside a story rather than beside it in the backlog.

Do all stories under an epic have to be user-facing? No, but most should be. Technical enablers are legitimate stories when they carry real risk or effort, such as a migration that must land before any feature work. Write them with the same clarity about what changes and how you will know it worked. If half your epic is enablers, you have a technical project that has been given a product name.

What do you do with an epic that never finishes? Close it and re-form what is left. An epic that has been open for two quarters has usually absorbed unrelated work, so its remaining stories no longer share an outcome. Ship what is done, move genuinely valuable leftovers into a new epic with a fresh outcome statement, and delete the rest rather than carrying it.

Slice vertically, cut the riskiest question first, and let the size of a story be decided by what the team can finish and show rather than by the tidiness of the board. Every other rule here is a rule of thumb you should be willing to break once you can say why.