How to write an epic that carries a value target

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, sized as capacity in the quarter's Tech Debt epic rather than priced as value.

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.

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. Tenhaw's founder, James Rooney, co-led the design and piloting of HSBC Global Payment Solutions' target operating model for 500 teams and a $450M portfolio, where who holds the pen on the money is exactly the sort of line such a model settles.

No. If neither delivers anything alone, they are one epic split for scheduling convenience, so 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.

Name it after the change in the world, not the thing you intend to build, so the title survives a change of solution. "Remove the forced account creation blocking guest checkout" passes that test. "Apple Pay integration" fails it, because it settles the design before research has run, and at validation the only question you can answer is whether you shipped it, not whether the number moved. Could a different implementation satisfy this title? If not, you have named a solution, not a change. Keep the title under about twelve words so it reads whole in a roadmap view, and put your current favourite solution in the body, where it can change without a rename.

Write it as three numbers and one multiplication: the population, the change you expect in it, and what one unit of that change is worth. For example, 480,000 checkout starts a year at 62% completion and an £84 average order value make one percentage point of completion worth 4,800 orders, about £403,000. State the headroom too, because the 38% who abandon are the ceiling, and a claimed 5pp lift needs evidence rather than enthusiasm. If the outcome is priced on profit, convert at margin. Tenhaw reports any month that returns no measurable value as a failed month, and that test needs this arithmetic. Put the whole chain in the ticket and use the same window, in-quarter or annualised, on every epic so the sums compare.

Then the gap is the finding, and week one is the time to say so, not week eleven. Price every epic under the outcome in one sitting, off one baseline reading, then sum them. Four epics at £200,000 under a £1m outcome is a £200,000 hole. Tenhaw runs that session with James Rooney in the room, because he leads every engagement personally. Apply your realisation rate as well, since a £1m target needs about £1.43m planned if you historically bank 70% of what you plan. From there, either find another epic worth the shortfall or restate the target as what the quarter can carry. Never price epics backwards so they sum neatly to the target, and give any residual gap an owner's name.

Then building the instrumentation is inside this epic's scope, not a follow-up. The measurement plan is written before anyone builds: the metric, the system it is read from, the baseline reading and 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. A baseline reading costs an hour before the build and cannot be reconstructed after it; skip it and validation becomes an argument about what the number was beforehand, and the epic gets closed as "probably worked". That plan is what monthly outcome validation judges the epic against once it is live.

Split it into two epics in consecutive quarters and give each its own share of the value. An epic belongs to exactly one roadmap, the quarter it ships in, and it is sized against the weeks that quarter really contains: minus holidays, minus the capacity already standing behind the Tech Debt and Bug Budget epics, forecast from your p85 throughput rather than a single-point estimate. What you must refuse is 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.

Everything a builder would otherwise ask you in conversation, because no later conversation is available. When a model does the build there are no stories beneath the epic, so the ticket itself carries the key user journeys end to end and the test requirements in full. The scope boundary becomes the load-bearing section, so write what is out of scope as plainly as what is in, because a vague boundary gets a model's interpretation of the gap, at speed, across the whole codebase. Tenhaw applies that standard in its open-source engineering handbook of 72 rules on GitHub, enforced by an agent. Teams where developers write the code with AI assisting pass the gate differently, with at least one product-approved story attached, so some detail can wait.

About half a day, and that includes both approvals. Most of that time goes on the arithmetic and the measurement plan rather than the prose, because the writing is short once the numbers exist: the population, the change you expect in it, what one unit of that change is worth, plus the baseline reading and the date it was taken. The baseline costs about an hour, and it cannot be reconstructed once the build has shipped, which is the whole argument for reading it now. Book the half day while you are breaking the outcome down for the coming quarter, not after the work has been scheduled. Tenhaw publishes the method in full, free to adopt without hiring anyone.

Same ticket type, plus a few more requirements that all point at a number someone will check. A value-focused epic links to exactly one outcome, is named after the change in the world rather than the build, and shows the money as visible arithmetic with the baseline reading and the date it was taken. It names the measurement before anyone builds, including who reads the metric each month and how long the epic must run before a real change is distinguishable from noise. It sits in exactly one quarter's roadmap. And it cannot leave Ready for Dev without both product and engineering approval.

Work backwards from its parent outcome before you touch the epic itself. If that outcome is not sitting in Committed with a currency target and a named owner, fix that first, because an epic priced against an unpriced outcome is guesswork with decimal places. At Tenhaw this is a roadmap-level repair, because an unpriced epic rarely travels alone. Then re-price every epic under the outcome in one sitting, off one baseline reading, with the same person holding the pen, so nothing gets claimed twice. Rename anything titled after a build. If the work still has no parent outcome after that conversation, it is not an epic. Route it to the quarter's Tech Debt or Bug Budget epic and move on.

Whether it fits the quarter, what it depends on, and what debt it creates. That is deliberately a different question from the one product asks, which is whether the value chain is credible and the measurement is real. Fit is the part that takes work. Size the epic against the weeks the quarter really contains, minus holidays, minus the capacity already standing behind the Tech Debt and Bug Budget epics, and forecast it from p85 throughput rather than a single-point estimate. An epic needs both approvals plus its mode's gate content before it can leave Ready for Dev, and no story beneath it can leave the backlog until product has approved the epic.

Because three months later, when the number has not moved, that record is the only honest account of what you knew at the time. Log every objection raised at either approval and how it was resolved, including the ones you overruled. It costs a paragraph, and it turns validation from an argument about who said what into a review of a decision that had reasons attached. It also protects both people involved, the one who raised the concern and the one who overruled it, because both positions were written down at the time rather than reconstructed afterwards.

Look for round numbers that sum to exactly the outcome target with nothing left over. That is the tell for epics priced backwards to satisfy the arithmetic rather than measured, and the first honest baseline reading collapses the roadmap. Two more tells are a missing baseline reading and date, and a value with no visible chain from population to expected change to unit value, so nobody else can re-run the sum. A fourth is two epics both claiming a lift on the same funnel step, which happens when siblings are priced in isolation, by a different person on a different day. Tenhaw reads a roadmap for these four tells first, because each is visible on the page without asking anyone.

Either, provided every epic on the roadmap uses the same window and the ticket says which one. A roadmap where one epic is annualised while its sibling is priced in-quarter will not add up against the outcome target, because the sums only mean anything if they compare. Pick the window that matches how the business reports, and settle it once at the start of the quarter rather than epic by epic. Whichever you choose, say in the ticket how long the epic must run before a real change is distinguishable from noise, because an annualised number is still judged on weeks of live data, not a year of it.