epic_breakdown v1.0.0

name: epic_breakdown description: "Split a big product epic into stories that can ship one by one: nine slicing patterns covering workflow steps, business rules, data variation, and operations, spotting fake slices that are really horizontal layers, ordering slices so the first one tests the riskiest assumption, and writing acceptance criteria per slice. Use when an epic is too big for one iteration, a backlog item cannot be estimated, or a team is about to split work by database, API, and UI instead of by value."

Epic Breakdown

Purpose

Turn one epic that is too big to build, estimate, or learn from into a short ordered list of stories, each one small, end to end, and worth shipping on its own. The test for every slice is simple: a user can do something after it ships that they could not do before, and the team can show it working.

This skill ships three tools. Use all three every time:

• Pattern cards for the nine slicing patterns: references/pattern-cards.md
• A slicing worksheet to fill in for the epic in front of you: assets/slicing-worksheet.md
• One epic split end to end, with its order defended: references/worked-epic.md

Workflow

1. Prepare the input. Confirm you actually have an epic.

• Write the epic in one sentence from the user's side: who does what, and what changes for them.
• If the input reads like a task or a component ("build the database for X", "as a developer I want an API for Y"), stop. That is the most common cause of an unsplittable story, per Richard Lawrence at Humanizing Work. Find the feature those tasks came from, combine them back into that feature, and split the feature instead. Go big before you go small.
• If the work has no user-visible change at all and no value in shipping part of it (a straight port, a fixed migration with a clear definition of done), say so plainly. Plan it as a small project with milestones, not as stories. Do not force slices onto it.

1. Name the riskiest assumption before you slice anything.

• List what has to be true for this epic to be worth building: users want it, a rule is allowed, a third party behaves as documented, the data exists, the flow is usable.
• Mark the one assumption that is both most uncertain and most costly if wrong. Slice 1 exists to test that assumption. If you cannot name it, ask the requester what would kill this epic if it turned out false. That answer is usually it.

1. Walk the nine patterns in order and write down every cut they suggest.

• Full cards, with the question to ask and a before-and-after example for each: references/pattern-cards.md.
• 1. Workflow steps: keep a thin path through every step, defer optional steps.
• 2. Operations: split a "manage" verb into its separate operations, often create, read, update, delete.
• 3. Business rule variations: one story per rule family or per rule that changes behaviour.
• 4. Data variation: one story per data type, format, source, or option the story handles.
• 5. Data boundaries: support the few key fields or attributes first, add the rest later.
• 6. Interface variation: simplest interface or one channel first, richer interfaces later.
• 7. Simple before complex: happy path and the plain case first, exceptions and edge cases as their own stories.
• 8. Major effort: do one of a set of similar variants first, then a second story for the rest, given the first is done. Name the dependency instead of hiding it.
• 9. Defer performance and hardening: make it work for a small load or a narrow case first, then a separate story for speed, scale, or stricter non-functional needs.
• One pattern rarely finishes the job. Most real epics need two or three applied in sequence: workflow first to find the thin path, then rules or data to shrink that path further.
• If uncertainty itself blocks every cut (nobody knows whether an approach works), pull that uncertainty out as a time-boxed spike, a learning story with a question and an end date, not a build story. That is the S in Mike Cohn's SPIDR set (Spikes, Paths, Interfaces, Data, Rules). Run the spike, then re-slice with what it taught you.

1. Reject fake slices.

• Horizontal layers: "build the schema", "build the API", "build the screens" as separate stories. No layer alone gives a user anything, nothing can be shown until all three land, and integration risk stays hidden until the end. Rewrite each one as a thin cut through all the layers it needs.
• Steps with no payoff: slicing a workflow into step 1, step 2, step 3 where a user gets nothing until the last step ships. A workflow slice must still let someone finish a real, if narrow, job. Narrow the user, the data, or the rule before you narrow the path to a single step.
• Tasks in story costume: a slice whose "user" is the team, the database, or another component. Tasks belong under a story, not in place of one.
• Equal-size padding: slices cut to look the same size by adding low-value scope to small ones or splitting a coherent behaviour in half. Size follows the cut, not the other way round.
• Hidden big first slice: a first story that quietly contains most of the epic (all the setup, all the rules) with small stories trailing it. If slice 1 is much bigger than the rest, pattern 8 it: one variant first, the rest given that one.

1. Check every surviving slice against INVEST.

• Bill Wake's test, from 2003: Independent, Negotiable, Valuable, Estimable, Small, Testable.
• In practice, check the three that fail most often after a split. Valuable: could you demo this slice alone and would a user care? Small: can one team design, build, and test it inside one iteration? Estimable: is it clear enough that the team will size it without a shrug? A slice that fails one gets re-cut or rewritten, not carried forward with a note.
• Accept a stated dependency only under pattern 8, and write it on the slice ("given slice 2 is done") so planning sees it.

1. Order the slices.

• Slice 1 tests the riskiest assumption from step 2 while still shipping something a user can use. A pure research slice goes first only if it is a spike, and the spike is labelled as one.
• After slice 1, order by value per effort, with one adjustment: pull forward any slice that retires a second large risk (a rule you are not sure is allowed, an integration you have not proven).
• Push pure breadth last: extra data types, extra interfaces, extra variants, and hardening. Breadth is where epics hide most of their cost and least of their learning.
• Write one line per slice defending its place in the order. If you cannot defend a position, the order is a guess. Say which line is a guess.

1. Write acceptance criteria for each slice.

• Pick the format by the shape of the behaviour:
• Behaviour changes with context or input: use Given-When-Then scenarios. One happy path, plus the one exception that matters most for this slice. Use concrete example values, not placeholders like "a valid input".
• The slice is mostly rules or conditions: use a plain checklist of testable statements ("the system shows X when Y", "a user cannot do Z"). Do not force rules into scenario costume.
• Keep it to 3 to 5 criteria per slice. More than that usually means the slice is still two stories.
• Each criterion must be pass or fail on sight. Cut words like fast, easy, or user-friendly unless a number or an observable state backs them.
• State what is out of scope for the slice in one line. Most rework comes from scope the team assumed was in, not from criteria that were wrong.

1. Fill in the worksheet and hand it over.

• Complete assets/slicing-worksheet.md for the epic: input sentence, riskiest assumption, patterns tried, slices rejected and why, final ordered list with criteria, and open questions.
• Compare your result once against references/worked-epic.md. Not for its answers, for its shape: does your split have a thin first slice, a defended order, and criteria a tester could run without asking you anything?

Output Contract

Return all of the following:

• The epic restated in one user-side sentence, plus a note if the input had to be rebuilt from tasks or components first.
• The riskiest assumption, named plainly, and which slice tests it.
• The ordered slice list. For each slice: a story title in user terms, the pattern or patterns that produced it, a one-line statement of what a user can do after it ships, any stated dependency, and its acceptance criteria (3 to 5, in Given-When-Then or checklist form).
• A rejected cuts list: each fake slice you discarded (horizontal layer, step with no payoff, task in story costume) and the reason.
• Open questions that block estimation or the first slice, separated from questions that can wait until later slices.

Operating Rules

• Vertical beats horizontal, every time. If a proposed slice cannot be shown working to a user, it is not a slice.
• Slice 1 is for learning, not for coverage. Do not lead with the most common case if a rarer case carries the risk that could kill the epic.
• Never invent rules, limits, dates, or system behaviour to make a slice look complete. If a rule is unknown, it goes in open questions and the criterion that depends on it is marked as blocked.
• Keep the epic visible above the slices. Every slice should still trace back to the one-sentence epic, so the team can tell when the remaining slices are no longer worth building.
• Stop slicing when the next cut would produce a story with no user-visible change. Below that line the work is tasks, and tasks live under a story.
• Re-slice after slice 1 ships if what it taught you changes the assumptions. A split is a plan based on what you know now, not a contract about what you will know later.