Key takeaways
  • An epic is too big for one sprint, but small enough to ship inside a quarter.
  • Avoid the "epic that lasts a year" and the "epic that's really two stories".
  • Epics need acceptance criteria too, and a place they're actually tracked.

Almost every backlog I am asked to look at has the same hidden problem. There are stories, and there are epics, and the epics are doing one of two things: they are either holding so much work that "the integrations epic" has been open for nine months, or they are holding so little that the team has invented an epic per story for the sake of tidiness. Both modes are wrong, in opposite directions, and both come from the same cause. Nobody on the team has ever agreed what an epic is for. So the artefact drifts, the hierarchy stops meaning anything, and roadmapping becomes a fight about labels rather than about outcomes.

The epic is a real, useful unit of work. It sits in a specific place in the hierarchy. It has a specific size. It has acceptance criteria that aren't just the union of its stories. And if you treat it that way, the rest of the backlog, and most of the roadmap conversation, gets quieter and faster.

Where the epic sits in the hierarchy.

The standard product hierarchy has four levels: strategic at the top, tactical at the bottom. Atlassian's classic framing covers the middle two, but you need all four to keep your head straight:

  • Initiative. Three to six months of work, tied to a quarterly or half-year outcome. "Increase activation rate by 20%." It is a goal, not a deliverable, and several epics will sit beneath it.
  • Epic. Six to twelve weeks of work, ships a meaningful outcome, contains stories that can sequence. The unit we are talking about today.
  • Story. One to a handful of days of work, ships a meaningful slice of user value, fits inside one sprint. The unit the team commits to.
  • Subtask. Hours to a day. The mechanical breakdown an engineer makes for themselves. Not visible at the roadmap layer.

The epic is the layer where strategy meets backlog. Above it, the conversation is about outcomes and priorities. Below it, the conversation is about implementation detail. The epic is the only level at which both conversations have to be coherent at once. That is why the artefact is uniquely hard to get right, and uniquely valuable when you do.

Diagram · The four-tier work hierarchy, with the epic in focus
The four-tier work hierarchy — Initiative, Epic, Story, Subtask A tree diagram. At the top sits a wide ink rectangle labelled Initiative — three to six months. Beneath it, two marigold rectangles labelled Epic — six to twelve weeks — highlighted because they are the focal unit. Vertical lines connect the initiative to each epic. Beneath each epic, four small story boxes labelled User Story, drawn as ink outlines. Beneath each story, three small subtask ticks. Each tier has a duration label on the right side. The diagram emphasises the epic layer as the meeting point between strategy and backlog. TIER 01 INITIATIVE · 3–6 months TIER 02 EPIC · 6–12 weeks TIER 02 EPIC · 6–12 weeks USER STORY USER STORY USER STORY USER STORY USER STORY USER STORY Subtask Subtask Subtask Subtask TIER 03 days each TIER 04 hours each The epic is where strategy meets backlog. Above it, outcomes. Below it, implementation. The epic has to talk to both. Initiative → Epic → Story → Subtask. Four tiers. Two conversations. One artefact in the middle.
The four-tier hierarchy. The epic (highlighted) is the one tier that has to be legible to both strategy people upstairs and engineers downstairs. That dual-audience job is why it is the hardest level to write well, and the most useful when you do.

What makes a good epic.

A working epic clears three tests. If any of them fails, you don't have an epic. You have something else mislabelled.

  • Deliverable in 6–12 weeks. If your team is roughly two-week sprints, an epic spans three to six sprints. Less than three and it is probably one or two stories. More than six and it has quietly become a project (see the next section).
  • Ships a meaningful outcome. The epic, when shipped, changes something for a user, a buyer, or the business. "Improve checkout conversion by removing the second address field, the unnecessary phone field, and the duplicated CTA" is an epic. "Refactor the checkout module" is not. It has no outcome a non-engineer can name.
  • Contains stories that can sequence. An epic that fits in 6–12 weeks but whose stories all have to ship together is a single big story pretending to be an epic. The stories inside an epic should be able to ship in order, each one delivering some thin slice of the eventual outcome.

The name matters too. Name the epic after the outcome, not the work. "Reduce checkout drop-off" is better than "Checkout improvements". The first tells you when you're done. The second never ends.

The "epic that lasts a year" anti-pattern.

Most teams I work with have at least one. The "Integrations" epic. The "Platform" epic. The "Performance" epic. It was opened in February and it is still open in November, has had thirty-eight stories added to it, and the original acceptance criteria, if anyone wrote them, bear no relationship to what's actually being delivered today.

This isn't an epic. It is a theme, or a programme, or a project, pretending to be one delivery unit because someone wanted a single row on a roadmap. The damage is real. You cannot prioritise it against other epics because it has no end date. You cannot say "this epic is done" because the goalposts have moved twice. You cannot report progress because there isn't a fixed denominator. It is a piece of furniture in your backlog.

The fix is mechanical. Close it. Identify the actual outcome you are chasing this quarter, scope it to 6–12 weeks, name it, and open a new epic. Park the leftover work in the next initiative-level conversation. Hard to do, easy to defend.

An epic that lasts a year isn't an epic. It's a project pretending to be agile.

The "epic that's two stories" anti-pattern.

The opposite failure. The team, usually one that has just adopted Jira or Linear, has been told the hierarchy goes Epic → Story, and so every story gets a parent epic. The "Add password-reset link" epic contains exactly one story: "Add password-reset link." A second story might be "Update copy on confirmation email." That's the entire epic.

This is an artefact of tidiness, not work-shaping. It clutters the backlog, makes filters and reports meaningless, and trains the team to think of epics as folders rather than as delivery units. The fix is to delete the empty epics, let stand-alone stories live as stories, and reserve the epic label for actual 6–12-week units of work. Hierarchy is a tool. It is not a moral position.

Acceptance criteria: yes, epics have them.

Most teams put acceptance criteria on stories and stop there. They are wrong to. The epic needs its own AC, written at the epic's level of abstraction. Story AC says "the form validates on blur." Epic AC says "users abandoning at the address step has dropped by 30%, measured over four weeks." Story AC is checkable in QA. Epic AC is checkable in analytics, two to six weeks after the epic ships.

If you can't write the epic's AC, you do not yet know what the epic is for. That's a useful signal. It usually means the work is theme-shaped, not epic-shaped, and the priority conversation needs to go back upstairs.

Where to track epics.

Two artefacts, two homes. The epic as backlog unit lives in your delivery tool (Jira, Linear, ClickUp, Asana), alongside its stories. That's where engineering refines it, sequences it, and ships it. The epic as roadmap line lives on the roadmap (see N°31), where stakeholders see it as a strategic commitment with a quarter and an outcome.

These are the same artefact, displayed at different fidelities to different audiences. The mistake teams make is treating them as two different things and writing two different names for the same epic. One source of truth. Two views. The epic in Jira and the epic on the roadmap have the same title, same outcome, same delivery window. If they don't, the team is quietly running two priorities.

How we use this at Product Pieces.

When we run the Backlog Set Piece with a partner team, half the engagement is unscrambling epics. The themes get broken back into proper epics. The single-story "epics" get collapsed. The titles get rewritten in outcome language. And every epic walks out of the room with three things: a delivery window of 6–12 weeks, an acceptance criterion that can be measured, and a sequence of stories that can ship one at a time.

The team then has a backlog you can actually look at: a small number of in-flight epics, each tied to an initiative above it, each containing a few sharp stories below it. The roadmap conversation becomes a conversation about which epics to start next quarter. That conversation is short. That's the whole point.

Next issue: N°05, The Retrospective. Blameless, or pointless.