Christian Neiderstam ← All artifacts
Facilitation tool · not a Scrum artifact

Epic slicing

For turning one capability area into Epics that hang together, without a wall of sticky notes.

Stage 5 of 7 · Chapter 8 · Jump to the prompt

This tool belongs to stage 5 of seven: EPICS. WHY VISION GOAL WHAT EPICS STORIES DONE

What an Epic is

A slice, not a layer.

An Epic should be deliverable on its own, and large enough to hold several User Stories.

The method — walk the user forward and ask what breaks next

This is the whole technique, and it beats brainstorming decisively.

They log in. Then what?
They've got a barcode. What does it do?
It gives them a discount. How did they know to look for it?
They saw the discount. What makes them feel it was worth it?

Each answer is either an Epic you already have, or one you are missing.

And it is why the set holds together. Five Epics derived by walking a single journey hang together naturally. Five Epics brainstormed onto sticky notes almost never do.

Each Epic is triggered by a question about the one before it. If you cannot say which question produced an Epic, it probably came from somebody's preference rather than the journey.

And if you do have to show the list — get it said out loud.

Reading a candidate to the room is not the same as the room agreeing to it. Put it up, then wait for somebody to restate it in their own words, and for at least one other person to push back or add to it. Only then is it theirs.

Because if it stays in your wording, you will be quoted as the author of it — and the first time it is questioned, everyone will look at you rather than at the person accountable for the outcome. That is a bad place for a Scrum Master to be standing, and it is entirely avoidable.

The prompt

The amber parts are the ones you replace.

Epic slicing prompt 
I am the Scrum Master, preparing an Epic slicing workshop.
I am NOT producing the final Epics — the team slices them,
walking the journey together.

Give me a journey they can walk and argue with.

CONTEXT
  Capability area:  [the single High-Level What being
                     decomposed — paste it in full]
  Product Goal:     [paste it]
  Primary user:     [who this capability serves, specifically]
  Known systems:    [anything this must integrate with,
                     and who owns it]

PRODUCE

PART ONE — THE JOURNEY

Walk the primary user through this capability, step by step,
in plain sentences. At each step, state what they now have
and what breaks or is missing next. Six to ten steps.

Do not name Epics yet. Just the journey.

PART TWO — THE SLICES

From that journey, propose four to six candidate Epics.

For each:

1. NAME — a slice a user could benefit from, phrased as
   an outcome.

2. WHICH STEP IN THE JOURNEY TRIGGERED IT — quote the
   step. If an Epic has no trigger, remove it.

3. SLICE OR LAYER? — state plainly whether a user can do
   something at the end of this Epic. If the honest answer
   is no, mark it as a layer and say what it would need to
   become a slice.

4. COULD IT SHIP ALONE? — and if not, name what it needs
   first.

PART THREE — THE ONE WORTH WORRYING ABOUT

Identify any Epic that depends on a system the team does
not own — a point-of-sale platform, a payment provider, an
identity service, another team's API.

For each, say:
  who owns it
  what would have to be true before work could start
  what the team could build that does not depend on it

Flag this even if it looks minor. External dependencies are
the most common reason a well-sliced Epic set fails, and
they are always visible at this stage if somebody looks.

CONSTRAINTS
  One capability area at a time. Do not decompose several.
  Do not write User Stories. That is the next session.
  Do not estimate anything.
  Refine only what is next. Leave the rest coarse.

What it produced for Beauty Spot

One capability area — personalised digital identity and in-store benefits — walked forward as a journey, then sliced.

The journey, then five slices
journey What breaks next, step by step A member downloads the app — and can't do anything, because there's no account. She has an account — and there's nothing in it. She has a profile — but nothing to show at a till. She has a barcode — and the assistant doesn't know what to do with it. It scanned — but she doesn't know what she just got. She got a discount — and can't tell whether membership is worth it.
E01 Secure authentication and profile setup Triggered by: “can't do anything, there's no account”. Slice — a user can register and sign in. Ships alone.
E02 Digital barcode generation and display Triggered by: “nothing to show at a till”. Slice. Needs E01 first.
E03 In-store benefit redemption via barcode Triggered by: “the assistant doesn't know what to do with it”. Depends on the point-of-sale platform, which Beauty Spot does not own.
E04 Benefit and discount visibility Triggered by: “doesn't know what she just got”. Slice. Ships alone.
E05 Loyalty points balance and history Triggered by: “can't tell whether membership is worth it”. Slice. Ships alone.

Part three did its job. E03 depends on a point-of-sale platform nobody on the team had ever spoken to, and the prompt said so before a line of code existed.

That warning was available in a refinement session. It became an impediment two Sprints later, and a missed Sprint Goal after that. The dependency did not get worse — it just stopped being visible once everybody was busy.

The timing question

Decompose one capability area, not all of them.

Refinement done too early is waste — it will change before anybody builds it. Refinement done too late means Sprint Planning becomes a design session and the Sprint starts a day behind.

The signal: refine the next capability area when the current one has roughly one Sprint of Ready work left in it. Not before.

The homework applies here too.

Everything in this session lands better if you already know where the sector is going and how this client arrived where they are — the mergers, the exits, the restructure nobody mentions. It is what lets you hear what is underneath a stakeholder's first answer.

There's a research prompt for it on the business drivers page.

Running the session

Before

Pick one capability area. Have the Product Goal visible. Bring the journey draft only as insurance.

In the room

Developers are here now. This is where technical judgement changes the answer, unlike the capability session.

Walk the journey out loud, together. Ask “then what?” and “what breaks next?” and let the room answer. Write Epics only after the journey exists.

Then ask of each Epic: can a user do something at the end of this? The ones that fail are layers wearing an Epic's name.

Flag the external dependency. Not to solve it — to make it visible while there is still time to plan around it.

After

Leave the other capability areas alone. They stay coarse until their turn.

Limits

A model can walk a plausible journey. It cannot tell you that your point-of-sale vendor takes four months to answer an email, or that the identity service is being replaced next quarter.

Epics are not Scrum. The Guide has Product Backlog items and says nothing about Epics, themes or capability areas. Jira has an Epic issue type, which is why most teams assume it is framework. It isn't — it is a useful practice, and you should be able to say which is which.

The same pattern elsewhere

Wrong-list-first works anywhere a group has to produce something from a blank page.

Transparency

An artifact board everyone can open

Transparency is one of Scrum's three pillars, alongside inspection and adaptation. Without it the other two have nothing to work on. It's also what makes a why-to-done chain worth building.

Every outcome of that chain should be readable by anyone involved in the project, formally or informally. Not a folder somebody has to request access to. A board you can open.

That matters most in the later stages. You're four Sprints in, arguing about whether something's in scope. The answer usually sits in a decision made months earlier. And the only useful version of it is the one written down at the time, not the one people remember.

It also means the chain can be inspected. Markets throw curveballs and businesses change their minds. Drivers that were right in January can be wrong by June. Put them somewhere visible, revisit them on a deliberate cadence, and the chain adapts. Leave them in a document nobody reopens and it quietly stops being true.

The stakeholders own the top of that chain — the drivers, the vision and the Product Goal — so they're the ones who inspect and adapt it. Not the Scrum Master, and not the team. Your job is to put the question in front of them on a cadence they've agreed to, and to make sure what they decide gets written where everyone can see it.

Beauty Spot's board is public, and free to read whether you buy the book or not.

Open the board →

This is one of thirty-one artifacts from Worth Building with Scrum: From Why to Done — the chain from a business driver to a line of finished code, worked through one team's four Sprints. About the book · read chapter 1 free.