Epic vs story: what the three backlog levels are for, and when a small team needs an epic

Picture a four-column board with five developers on it. Near the top of the current sprint sits a card called "Billing". Thirteen points. It has been pulled into three sprints in a row and finished in none of them, because it is not one piece of work, it is a payment provider integration plus an invoice PDF plus a dunning email. Two rows below it, someone has quietly created "Billing part 2", which is where the leftovers go.

Nobody on that team is confused about how to write a story. They know that card is three stories. What they are missing is somewhere to put the shape of the whole thing, so the shape leaks into the titles instead.

That is the job an epic does, and it is a narrower job than the three-tier diagrams suggest. A story is a slice of work you can finish inside one sprint. An epic is a container for work you already know will take several, kept as one thing so you can answer questions about it. A task is a step inside a story. Of those three words, none appear in the Scrum Guide, which is worth knowing before you reorganise a backlog around them.

Where the three levels actually come from

Scrum has one kind of thing in the Product Backlog: a Product Backlog item. That is it. The Scrum Guide never says epic, never says story, never says subtask. The closest it gets to decomposition is a line about Sprint Planning, where developers plan the work by "decomposing Product Backlog items into smaller work items of one day or less". Those smaller work items live in the plan for the sprint, not as a permanent tier in your backlog.

The vocabulary everyone uses instead came from tools, and mostly from one. Jira ships with three hierarchy levels out of the box: level 1 called Epic, level 0 called Story, and level -1 called Subtask. An epic can parent stories, tasks and bugs. A task can parent subtasks. A subtask can parent nothing. Adding levels above Epic, the portfolio tier, requires a Premium or Enterprise subscription. Because a whole generation of teams learned Scrum by clicking around Jira, that shape now reads as if it were part of the framework.

It is not, and other tools quietly disagree. Linear has no epic at all: it uses Projects, with Initiatives above them, and when you import from Jira your epics come across as Linear projects. Two serious tools, two different vocabularies for the same idea. If somebody tells you the three levels are "how agile works", they are describing a product decision.

None of this makes the levels wrong. Naming things bigger than a sprint is genuinely useful. It just means you get to decide whether you need them, rather than inheriting them.

What separates an epic from a big story?

One line: the sprint boundary. A story that fits in a sprint is a story, however large it feels. Work that cannot fit, by design and not by accident, is an epic.

The second difference matters more in practice and gets mentioned less. A story is something you finish. An epic is something you report on. You estimate stories, you close stories, you demo stories. An epic has no size of its own; whatever its stories add up to is its size. Its whole value is being able to say "checkout is nine of fourteen stories done, and the date we promised is in three weeks" without opening fourteen cards.

Which gives you the useful test. If nobody is asking that question, you do not need the container. You need to split the story and get on with it.

When a small team genuinely needs one

I used to think epics were pure Jira ceremony for small teams, a field you fill in because the form has it. I have changed my mind about half of that, and the half that changed is specific: epics stop being overhead the moment the board is no longer a complete answer to "how is it going".

That happens for three reasons, in my experience roughly in this order.

1. Something will outlive several sprints and somebody outside the team keeps asking about it. Not about this sprint, about the feature. Answering that by scrolling a backlog is a tax you pay weekly.
2. Two or three streams of work are running at once, and the board has become one undifferentiated pile of cards. You can still read every card, but you cannot see the two efforts.
3. A date is attached to something bigger than a sprint. Nothing exposes the gap between "we are busy" and "we will make it" faster than a target date on a thing you have no rollup for.

Underneath that, an epic buys you very little. If you have one thing in flight and a backlog you can take in at a glance, epics are a solution looking for a problem, and a taxonomy nobody maintains is worse than no taxonomy. The honest concession is that plenty of small teams never cross that line, and their refinement sessions are better for it.

Do you need a task level at all?

Mostly no, and this is the level I would push back on hardest.

Scrum's actual decomposition, the "work items of one day or less", is a planning conversation. It happens in Sprint Planning, it produces a plan for the sprint, and it does not need to become a permanent tracked record with its own status, assignee and audit trail. When it does, two things happen. The number of things people have to drag doubles, and the accuracy of the board halves, because nobody updates six subtasks to move one story.

Subtasks make the board honest for the person doing the work and slightly useless for everyone else. That is the trade, and it is a bad trade for a team of five. If a story genuinely needs six visible steps, put them in the story as a checklist, or accept that the story is too big and split it along a seam that still ships.

This is why Scrumpy has no subtasks, on purpose. What it does have is a story type called Task, which is a different thing entirely: every team starts with Bug, Feature and Task as types, all at the same level, distinguished by an icon and a colour. A framework upgrade with no user-facing benefit is a story typed Task. It sits on the board next to everything else, gets a size, and gets finished. It is a label, not a tier.

An epic should be able to end

The most common way epics go wrong is not having too many. It is creating them as a filing system for your product: Frontend, Backend, Tech Debt, Mobile. Those are categories, and categories never finish. Two years later you have an epic called Tech Debt with 140 stories in it, which tells you nothing at all.

Here is the sentence to test against: "this epic is done when ______". If you cannot finish it, you have made a folder, not an epic. "Self-serve billing works end to end" finishes. "Backend" does not.

Scrumpy leans on that fairly bluntly. An epic can only be closed once every story inside it is done or cancelled, and it refuses to delete an epic that still has stories attached. The effect of that small constraint is worth more than it sounds: an epic you cannot finish just sits on the page looking unfinished, which is the correct feedback.

What an epic actually is in Scrumpy

Deliberately small, so it is worth being precise rather than letting you assume Jira's version. An epic in Scrumpy is a name, a colour, an optional description and an optional target date. A story belongs to at most one epic. There is no nesting: no epic of epics, no portfolio layer above it, no hierarchy to configure.

On the board and in the backlog, the epic shows up as a coloured stripe down the left edge of the card, with the epic name on hover, and you can colour whole cards by epic if you want the two workstreams to be visible from across the room. Filtering the board or backlog down to one epic takes a click.

The Epics page is where the reporting lives: a card per epic showing "7 / 12 stories done", a progress bar in the epic's colour, how long it has been in progress, the target date, and a status badge worked out from progress against elapsed time. On track, Behind, Overdue, Delivered, or Delivered late. Behind means completion has fallen more than ten percent behind the share of the calendar that has gone by, which is a blunt heuristic and, in a small team, usually right.

One quirk worth knowing, because it will confuse you otherwise: the Epics page measures progress by stories completed, while the dashboard's epic widget measures the same epic by story points completed. Both are defensible, and they will show different numbers for the same epic when your story sizes vary. Read the one that matches the question you are asking.

The part that has nothing to do with tooling

An epic is a promise about scope, and a promise nobody agreed to is just a title. Before creating one, get the team to say out loud what would have to be true for it to be finished. That is the same instinct as a definition of done, one level up, and it is the difference between an epic that closes in six weeks and an epic that becomes furniture.

If you are being told to add epics and you cannot name the question they would answer, do not add them yet. Wait until the board stops answering something you get asked, then add exactly one epic for that thing and see whether the question goes quiet. In Scrumpy that is four fields and no configuration, so the experiment costs you a minute; if it does not help, close it and move on. That is a much better way to find out than reorganising a backlog you were getting on with fine.