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.
- steps
- 8
- named failure modes
- 5
- definition-of-done criteria
- 6
How to write a value-focused epic, in one paragraph
An epic is one quarter of work carrying a named share of exactly one outcome's currency target. Good looks like this: a reader opens the ticket and sees which outcome it ladders to, how much money it is planned to return, the arithmetic behind that number, the baseline it was measured from, the date that baseline was read, and how anyone will know afterwards whether it landed. No second document, no follow-up conversation. If the epic carries no number, it is a feature wishlist with a due date attached.
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.
Write one whenever an outcome has moved to Committed and you are breaking it down for the coming quarter. Also use it to repair an existing epic that nobody in the room can put a number against.
- Time to run it once
- About half a day, including both approvals
- What you need
- The delivery tracker
- The parent outcome's baseline reading
Step by step
Each step is deep-linkable, so you can send a colleague the one that is in dispute.
- 1
Start from a committed outcome
Open the parent outcome before you open a blank epic.
It should sit in Committed, carry a currency target and have a named owner; if it does not, fix that first, because an epic priced against an unpriced outcome is guesswork with decimal places. An epic links to exactly one outcome. If the work serves two, pick the one it moves most, claim value there only, and record the secondary benefit as a note so nobody banks it twice. If you cannot name a parent outcome at all, the work is not an epic: route it to this quarter's Tech Debt or Bug Budget epic and move on.
- 2
Name it after the change, not the build
Name the epic after the change in the world, not the thing you plan to build.
"Remove the forced account creation blocking guest checkout" survives a change of solution. "Apple Pay integration" does not, and it settles the design before research has run. Apply one test: could a different implementation satisfy this title? If not, you have written a solution, and at validation the only question you can answer is whether you shipped it. Keep the title under about twelve words so it reads whole in a roadmap view, and put the solution you currently favour in the body, where it can change without a rename.
- 3
Show the arithmetic a sceptic could re-run
Write the money as three numbers and one multiplication: the population, the change you expect in it, and what one unit of that change is worth. 480,000 checkout starts a year at 62% completion with an £84 average order value makes one percentage point worth 4,800 orders, about £403,000. State the headroom as well: 38% abandon, so there is a ceiling, and a claimed 5pp lift needs evidence rather than enthusiasm. If the outcome is priced on profit, convert at margin before writing the number. Put the chain in the ticket, and state the window, in-quarter or annualised, the same window on every epic.
- 4
Price the siblings together, then check the total
Price every epic under an outcome in one sitting, off one baseline reading, with the same person holding the pen.
Priced separately, two epics will both claim the payment screen and their combined lift will exceed anything that screen can produce. Then sum them against the outcome target: four epics at £200,000 under a £1m outcome is a £200,000 hole, and week one is the time to say so, not week eleven. Apply your own realisation rate on top: if you historically bank 70% of what you plan, a £1m target needs about £1.43m planned. Take the rate from your delivery history, and give the residual gap an owner's name.
- 5
Name the measurement before anyone builds
Write down the metric, the system it is read from, the baseline reading, the date it was taken, who reads it each month, and how long the epic must run before a real change is distinguishable from noise. At 480,000 starts a year, a 0.5pp move needs weeks of data before you can call it, so say that in the ticket and nobody demands a verdict in week two. If the metric does not exist yet, the instrumentation is inside this epic's scope, not a follow-up. This section is what monthly outcome validation judges the epic against once it sits in value monitoring.
- 6
Fit it to one quarter, then size it
An epic belongs to one roadmap: the quarter it ships in.
Size it against the weeks that quarter contains, minus holidays, minus the capacity already standing behind the Tech Debt and Bug Budget epics, and forecast from your p85 throughput rather than a single-point estimate. If it will not fit, split it into two epics in consecutive quarters and give each its own share of the value. Refuse the phase-one pattern where the first epic returns nothing and all the money hides in phase two: if a slice cannot carry a number of its own, it is not an epic, it is part of the next one.
- 7
Write the gate content your mode requires
Both modes need the outcome link, the currency share and the scope boundaries.
Write what is out of scope as plainly as what is in it, because that is the line a builder will otherwise redraw alone. AI-augmented teams then attach at least one product-approved story, small enough to build in a sprint and specific enough to test. AI-native teams stop at the epic, so the ticket itself carries the key user journeys end to end and the test requirements in full, written to be handed over whole to a model with no follow-up conversation available. If you would need a conversation to explain it, it is not finished.
- 8
Take both approvals and log the objections
Product approval and engineering approval ask different questions.
Product asks whether the value chain is credible and the measurement is real. Engineering asks whether it fits the quarter, what it depends on and what debt it creates. An epic cannot leave Ready for Dev without both approvals plus the mode's gate content, and no story beneath it can leave the backlog until product has approved the epic. Record every objection raised and how it was resolved, in the ticket, including the ones you overruled. Three months later, when the number has not moved, that record is the only honest account of what you knew at the time.
Worked example: a £1.2m outcome broken into three value-carrying epics
Take a fictional mid-market UK retailer. The outcome is "Recover revenue lost at checkout", target £1.2m annualised, owned by the commerce director. Baseline read from the analytics platform on 3 January: 480,000 checkout starts a year, 62% completion, £84 average order value. One percentage point of completion is 4,800 orders, about £403,000, and the theoretical ceiling is the 38% who abandon. Three epics are priced in one sitting against that single baseline, alongside the roadmap's standing Tech Debt and Bug Budget epics. One-tap wallet payment on mobile: mobile is 61% of starts, 292,800 a year, and 2pp there is 5,856 orders, £492,000. Remove forced account creation for guests: research supported 1.4pp, but mobile guests are already counted inside the wallet epic, so this one is priced at 0.9pp, 4,320 orders, £363,000, with the 0.5pp difference noted in the ticket as claimed next door. Address lookup plus readable card-decline messaging: 0.5pp, 2,400 orders, £202,000. Planned total £1.06m against a £1.2m target, a visible £144,000 shortfall before a line of code is written. Apply the retailer's own 70% realisation rate and it is worse: £1.06m planned lands nearer £739,000, and covering £1.2m credibly needs about £1.71m of planned epic value, so roughly £658,000 is missing. Two honest choices follow. Find another epic worth that much, or restate the outcome target as what this quarter can carry. What you cannot do is leave the sum unexamined and discover it in April.
Where this goes wrong
- 01
Naming the epic after the build.
"Apple Pay integration" gets written because the item arrived from a backlog that had already picked the solution. The cost lands at validation, where the only question you can answer is whether you shipped it, not whether the number moved.
- 02
Dividing the outcome target by the number of epics.
The tell is a set of suspiciously round values that sum to exactly the target with nothing left over. It means the epics were priced to satisfy the arithmetic rather than measured, and the first honest baseline reading collapses the roadmap.
- 03
Double counting the same funnel step.
Two epics both claim a lift on the payment screen, and their combined value exceeds anything that screen can produce, because each was priced in isolation by a different person on a different day.
- 04
Phase-one epics that carry no value.
All the return is deferred to a phase two next quarter, so the quarter closes with an epic that cannot enter value monitoring and cannot be validated. Splitting work is fine. Splitting it so that only the second half is worth anything is not.
- 05
Deciding the measurement after release.
Nobody captured the baseline, so validation becomes an argument about what the number was beforehand and the epic gets closed as "probably worked". A baseline reading costs an hour before the build and cannot be reconstructed after it.
Done means
- The epic links to exactly one outcome and sits in exactly one quarter's roadmap.
- It carries a planned currency value with the arithmetic shown in the ticket, plus the baseline reading and the date it was taken.
- Every epic under the outcome has been summed against its target, the realisation rate applied, and any remaining gap written down with an owner's name against it.
- The measurement plan names the metric, its source, who reads it monthly, and how long it must run before a change is distinguishable from noise.
- The mode's gate content is present: at least one product-approved story for AI-augmented teams, or the key user journeys plus the test requirements for AI-native teams.
- Product and engineering have both approved, and the objections raised along the way are recorded in the ticket with how each was resolved.
The arithmetic is identical in both modes; the gate content is not. An AI-augmented epic passes with at least one product-approved story attached, so some detail can wait for story writing. An AI-native epic is the unit of work, so the ticket carries the key user journeys and the test requirements in full and there is no later conversation to fill the gaps. That makes the scope boundary the load-bearing section: an AI-native epic that is vague about what is out of scope gets a model's interpretation of the gap, at speed, across the whole codebase.
The two delivery modes, side by side →Questions
What if the epic has no revenue attached, like a compliance deadline or a platform migration?
Price the avoided loss instead of the gain: the fine, the contract at risk, the run cost you stop paying, the hours the migration hands back to the team each month. Use the same currency and the same window as every other epic on the roadmap. If nobody will put a number on it after that conversation, you have learned something about its priority rather than found an exemption. Standing engineering work is different: it belongs in the quarter's Tech Debt epic, which is sized as capacity rather than priced as value.
How precise does the value estimate need to be?
Precise enough that someone else could re-run it and land in the same order of magnitude, and no more. The point is not accuracy to the pound, it is exposing the assumption: which population, what lift, what one unit is worth. A wrong number with visible arithmetic gets corrected in five minutes at validation. A confident number with nothing behind it cannot be corrected at all, only argued about.
Who writes the value, product or finance?
Product writes it and finance checks the conversion. The product manager owns the population and the expected lift, because those come from research and funnel data. Finance owns whether you are converting at revenue or at margin, and whether the window matches how the business reports. Getting that second signature once, at the start of the quarter, avoids the meeting in April where a £1m roadmap turns out to be £300,000 of gross profit.
Can two epics share one outcome's value if they only work together?
No. If neither delivers anything alone, they are one epic split for scheduling convenience: merge them, or move the combined work into a single quarter. If one delivers something alone and the other adds to it, price the first at its standalone value and the second at the increment only. Never write the same pound into two tickets.
More on setting up the work
These guides are written to be read in order.
04How 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.
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 do discovery research
Discovery is how a hypothesis stops being a hunch. Keep the evidence linked to the work, not buried in an archive.
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