Epics Are Bets

Part four of the product owner toolbox. The leave tool now has a vision. Next comes the first large piece of work.

An epic describes a large need or problem: big enough that solving it is a real investment, often big enough to need a lean business case. It’s the largest kind of backlog item and it should be easy to understand. It says roughly why something should be solved and what, nothing more.

Most backlogs treat epics as folders, a place to collect stories that belong together. That misses what an epic is for. An epic is a bet: we think that spending this much will produce that much. It’s worth treating it like one.

Write down the bet

Every epic needs a clear scope and an outcome hypothesis, plus hard measures that tell you whether the value actually arrived. I use a one-page canvas:

Field	What goes in
Title	The epic’s name
Key stakeholders	Who cares, by name
Description	The elevator pitch
Benefit	The added value for users and for the business
Outcome hypothesis	What we expect to change
Measures	The numbers that confirm or reject the hypothesis
MVP features	The smallest scope that tests the hypothesis
Non-functional requirements	What must hold regardless (availability, security, data location)

For the leave tool:

• Title: Request and approve leave online
• Description: Employees request leave in the tool, team leads approve it there, and HR sees the result without retyping anything.
• Benefit: HR stops maintaining a spreadsheet. Employees know their balance. Team leads see conflicts before they approve.
• Outcome hypothesis: Within one quarter, HR spends 80 % less time on leave administration.
• Measures: Hours HR spends per month on leave, measured before and after. Share of requests approved in the tool rather than by email.
• MVP features: Submit a request, approve or reject it, see the team calendar.
• Non-functional: Works in a mobile browser. Data stays in Switzerland.

The MVP is not version one

A minimal viable product is the simplest version of the product that lets the team test its assumptions. Eric Ries described the loop in The Lean Startup: build something small, measure how real users react to it, learn, and feed what you learned back into the product.

Its main job is to reduce risk. That can mean you don’t know enough about the users’ problem yet, or that you don’t know whether the technical solution will work. Either way, the MVP turns assumptions into knowledge, and that knowledge flows back into the product.

What an MVP is not is the first commercially usable version. That’s why it’s hard to judge it by return on investment. You’re paying for what you learn.

So use the cheapest thing that teaches you something: a paper prototype, a clickable mockup, a few lines of code. Any form works as long as it gets real feedback on the hypothesis. Afterwards, you either throw it away or build the next iteration on it.

For the leave tool, the riskiest assumption isn’t technical. It’s this: team leads will approve requests in a tool instead of replying to an email. If they won’t, nothing else matters. The cheapest test is a plain form that sends the team lead a link with two buttons, used by one department for four weeks. Count how many approvals go through the link and how many still go through email.

Show the bets

Epics are collected with the stakeholders at the start, but the list doesn’t stay the same. Strategic decisions and user feedback add new epics, change existing ones and remove others.

Put the epics on a Kanban board of their own. That makes progress visible to everyone, and it lets you watch cycle time and lead time. An epic that sits in “in progress” for nine months is telling you something.

Break epics down into features and stories only when you’re about to work on them, as described in just-in-time specification.

The permission to stop

This is the part most organisations skip. An epic includes its MVP and the business value the MVP should prove. If the value doesn’t show up after the MVP, stop the epic. If it does, build the rest.

Stopping is the outcome that saves the most money, and it’s the one that’s hardest to sell. Write the stop condition down before you start, when nobody has invested anything yet and nobody’s pride is involved.

Next

Before we break the epic into features, we have to know who we’re building for. Next time: personas and user journeys, and why a persona without research is a stereotype with a name.