Epic

An epic is how a validated problem becomes buildable work. A chunk of customer value big enough to need its own goal, small enough to actually finish. It's born from an opportunity card that finished its loop at the build door, and it breaks apart into stories once it's written.

There's no formal Scrum rule for any of this sizing. Epic isn't even an official Scrum artifact; it's a convention, the one Agile teams and Jira landed on for grouping related stories. So treat the ladder below as rule of thumb, not regulation:

Two of those rows run looser in the wild than I prefer to run them. The industry lets an epic stretch to three months. Mine finish in three to eight weeks, which could be a sprint and a half, or three sprints, or more, depending on how long your sprints run. That has worked out to 15 to 40 story points and 5 to 15 stories, because an epic that wants three months is a roadmap hiding in your backlog. The industry also allows tasks up to a couple of days. Mine cap at one, because a stuck one-day task gets caught at tomorrow's stand-up, and a stuck two-day task gets two quiet days to hide before anyone notices.

How to write each field well, the five tests, the Out of Scope discipline, all of that is the Epic Writing Guide. This page is the artifact.

The card, blank

Epic · Blank template

Epic Title

[Action] [Capability] for [User Type]

Problem Statement

When [situation arises],
As [user type], I want to [job to be done],
So that [end goal],
But [current reality preventing success].

Solution Overview

[Your approach, in two or three plain sentences. No jargon.]

Expected Outcome

[What users can do after this is complete that they couldn't before. An outcome, not a feature list.]

Success Criteria

[The outcomes and benchmarks that prove the work paid off: specific results, performance targets, analytics tracking live. Checkboxes, not prose.]

Acceptance Criteria

Given [context]
When [action]
Then [expected outcome]

[One per scenario. The Given/When/Then shape is the standard behavior-driven development convention, not mine.]

Out of Scope

[What this work deliberately does NOT include. Write it down, or you'll end up building it.]

Dependencies & Risks

Depends on

[other work or external factors]

Blocks

[what's waiting on this]

Risks

[technical, timeline, or resource concerns]

Metrics

Primary metric

[what improves when this works]

Secondary metrics

[supporting indicators]

Baseline

[where the number sits today]

Target

[where it needs to land]

Two craft notes before you fill it, both from the guide. First, the But line. Most problem statements stop at "so that." Yours shouldn't. The But forces you to name the current reality in the way, and if you can't fill it in, you don't have a project. You have an idea.

Second, fill it top to bottom. The order is the discipline. Problem before solution, outcome before criteria. The moment you catch yourself writing the Solution Overview first, you're not planning. You're decorating a decision you already made.

The card, filled

The invoicing case again, one step up the chain from the opportunity card you just read. The opportunity validated that late payment was friction at pay-time, not unwillingness to pay. This is the epic that solution became.

Epic · Filled example

Epic Title

Automate Payment Reminders for Finance Teams

Problem Statement

When an invoice goes past due,
As a finance lead, I want my customer nudged with a way to pay on the spot,
So that on-time payments rise and cash flow steadies,
But today every reminder is typed by hand and paying still takes a login and three screens.

Solution Overview

Automatically send reminder emails on a schedule once an invoice passes due, each carrying a one-click pay link.

Expected Outcome

A finance lead can turn reminders on once and watch the on-time rate, instead of chasing invoices one by one.

Success Criteria

• On-time payment rate moves from [baseline] to [target] by [date]
• The tracking that proves it is live before launch

Acceptance Criteria

Given an invoice is three days past due,
When the reminder schedule fires,
Then the customer receives an email with a one-click pay link.

Out of Scope

Partial payments (its own epic, next phase). Auto-charge opt-in (needs its own validation first). Anything inside the customer's internal approval workflow.

Dependencies & Risks

Depends on

the payments provider behind the pay link.

Blocks

nothing.

Risks

reminder emails read as nagging and get marked as spam.

Metrics

Primary metric

on-time payment rate.

Secondary metrics

days-to-payment, reminder opt-out rate.

Baseline

[from your data].

Target

[the commitment you set in the KPIs & Metrics section].

On a real card, those brackets hold numbers and a date. This case is a teaching fill, and I don't invent metrics, so yours come from your own data. What matters is the shape. A number to beat, a date to beat it by, and the tracking already counting.

Three fields on the card sound alike and aren't. Success criteria say whether the epic worked. Acceptance criteria, in the Given/When/Then shape, say each piece behaves as written. Metrics are the number block underneath, the baseline and the target that make the other two checkable.

Notice the Problem Statement is the opportunity's problem formula, carried over in the same shape and re-aimed at the finance lead. Don't rewrite it from memory. The epic inherits the validated language.

One wrinkle worth naming. The opportunity's test nudged a few days before the due date, and this epic's reminders fire after it passes. The lever the test validated was ease of paying, not the timing, so the timing got decided here, on the card.

How progress rolls up

Once the epic breaks into stories and the stories into tasks, the reporting takes care of itself, because every level is counted. Tasks carry hours and stories carry story points, the relative sizes a team agrees on while planning, so what rolls up is finished stories. A story finishes, and its epic's percentage moves. Put the epics under one opportunity and the opportunity has a number too, assembled by arithmetic nobody does by hand. Say the late-payment problem became four epics across four teams, 55 story points total, 25 of them done:

Opportunity: Suppliers paid weeks late
25 of 55 pts, 45%

Each team's board updates itself, and the number flows up.

That number tells you how far through the work you are. It does not tell you whether the problem is going away, and the difference matters. The problem's own number, the drop-off, the days-to-payment, whatever the opportunity exists to move, is measured separately. Read the two together. Work at 45 percent with the problem's number improving, and the bet is paying. Work at 45 percent with the problem's number flat, and you want to know that now, not after the other 55 percent ships.

And the readout is short, because the structure already did the aggregating. As the product person, I tell leadership how much of the customer problem has actually shipped, and what the problem's own number is doing. Engineering owns their epics' progress underneath. Nobody writes a report about any of it.

Two failure modes to watch for at the top and bottom of this handoff. An epic with no opportunity above it means somebody wanted it, it got written, and now a team is spending weeks on work that traces back to an opinion. Ask the question in planning, not after. An opportunity that quietly collapsed into one epic. Either the problem was smaller than you thought, and that's worth knowing, or one epic is swallowing three teams' work and hiding it. Check which one you've got.

Copy it in

Copy the blank into your tracker and write the next validated opportunity as an epic the same day it clears its loop, while the problem statement is still hot. Fill the problem first and make the But line honest. And when the card is full, don't let it sit. Break it into stories. That's the next template.