Epics, Features and User Stories: How Work Breaks Down

An agile epic is a large piece of work, described by the outcome it should produce, that is too big to finish in one iteration and is split into smaller pieces before anyone builds it. Those pieces are user stories, and some teams put a middle layer of features between the two. An epic is not a deliverable in itself: it is a container that keeps a big idea in one place while it is broken down, and it is done when its outcome is reached or the remaining stories are no longer worth building. Below: how to tell an epic from a feature and a story, how big each should be, how SAFe, Scrum and Jira use the word, a template for writing one, and how to get the same grouping without the layers.

For the whole ladder, from theme down to task and where bugs fit, see user story vs task. This page stays on the top of it.

What makes something an epic

Size, mostly, and nothing more exact than that. Mike Cohn, who popularized the term, writes that an epic is a large user story and that there is no magic threshold↗ (opens in a new tab) at which a story becomes one. In practice a piece of work gets called an epic when any of these is true:

• It will not fit in one iteration, or one or two weeks of work for the team.
• It contains several changes a user would notice separately, each of which could ship on its own.
• Nobody can estimate it with a straight face, because too much about it is still unknown.
• More than one person or team will work on it at the same time.

Tools add a second meaning: an epic is a level in the hierarchy. Atlassian’s documentation describes an epic in Jira as the default work type↗ (opens in a new tab) for capturing a large body of work, and notes that an epic’s scope can change as the team learns from development and customer feedback. Jira now calls issue types “work types” and projects “spaces”; the epic kept its name.

Epic vs feature vs user story

The three differ in size, in who writes them, and in what “done” means. A rough guide that most teams can adopt as written:

• Epic: an outcome, such as “customers can return an order online without calling support”. Weeks to months of work. Written by whoever owns the product. Done when the outcome is reached, measured by something other than “all the stories closed”.
• Feature: a capability a user would recognize by name, such as “print a return label”. A few weeks at most. Used by teams large enough that an epic needs a middle layer to plan around; many small teams skip it.
• User story: one change a user would notice, small enough to finish in a few days: “As a customer, I want to print a prepaid label so that I can drop the box off with the carrier.” Done when its acceptance criteria pass.

The word “feature” is the slippery one. In some teams it is the middle layer above; in others it means an epic; in others still, any new capability at all. Pick one meaning, write it in your team’s working agreement, and stop arguing about it.

How SAFe, Scrum and Jira use the words

• Scrum. The Scrum Guide↗ (opens in a new tab) has no epics, features or stories. It has Product Backlog items, which are refined into smaller, more precise items, and work items of one day or less that Developers plan for each selected item. Epics in a Scrum team are a convention the team adds, not part of Scrum.
• SAFe. The Scaled Agile Framework makes all three formal. Its epic is a significant solution development initiative that needs portfolio oversight, with a minimum viable product and a Lean business case, approved before full commitment. A feature is sized to be delivered by one Agile Release Train within one Planning Interval, and a story is small enough for one team to finish in a few days or less. SAFe’s own phrase is that features are to the Planning Interval what stories are to an iteration.
• Jira. By default Jira has three levels: epic above story (and the other standard work types), and subtask below. Atlassian’s page on configuring the hierarchy↗ (opens in a new tab) says that only Jira Premium and Enterprise can add levels above the epic, for initiatives that span several spaces.

So a SAFe epic and a Scrum team’s epic are different sizes of thing. If two groups in your company use the word, ask which one they mean before you compare plans.

How to write an epic: a template

An epic needs less detail than a story, not more. Its job is to say what success looks like and where the edges are, so that the stories can be cut later by people who were not in the room. One page is plenty.

Epic:          Online returns
Outcome:       Customers can return an order online without
               calling support.
Who benefits:  Customers in the US who bought online; the support team.
Measure:       Return-related support calls fall; returns still
               get processed within 5 business days.
In scope:      Start a return from the order page, prepaid label,
               refund to the original card.
Out of scope:  Exchanges, in-store returns, international orders.
First slice:   One item, one reason, label by email, refund after
               the warehouse scans it.
Open questions: Who pays shipping on "changed my mind" returns?
Stories:       (filled in as it is split; see below)

Sizing an epic, and when to split it

Do not estimate an epic closely. The Agile Alliance glossary discourages estimating epics↗ (opens in a new tab) at all, because their scope is vague and uncertain. A T-shirt size (S, M, L, XL) or a range in weeks is enough to decide whether it is worth doing now. The stories are where estimates start to mean something.

Split an epic just before the team needs its first stories, not months ahead. Common ways to cut it:

• By workflow step: start a return, get a label, ship it, get the refund.
• Simplest case first: one item, one reason, then multiple items, then partial refunds.
• By user type: a signed-in customer first, a guest checkout order second.
• By business rule: the standard 30-day window first, the holiday extension later.
• By what is unknown: a short spike to answer the shipping-label question before committing to stories that depend on it.

If the steps a user takes are the hard part, lay them out first with user story mapping, then cut the map into releases.

A worked example: one epic, broken down

Epic: Online returns
  Feature: Start a return
    Story: As a customer, I can choose an item from a past order to return
    Story: As a customer, I can pick a reason from a short list
  Feature: Return label
    Story: As a customer, I get a prepaid label by email
    Story: As a customer, I can print the label again from the order page
  Feature: Refund
    Story: As a customer, my refund goes to the card I paid with
           once the warehouse scans the box
    Story: As support, I can see a return's status without asking
           the warehouse

Each story is written and checked the usual way; the user story template covers the format and acceptance criteria. Notice that the epic’s measure (fewer support calls) is not any one story’s acceptance criteria. That is why closing the last story does not by itself close the epic.

A flat alternative: groups instead of layers

A small team often gets the benefit of an epic, keeping related work findable, without the layer. Keep every piece of work at one level and group it instead:

• A naming convention. Prefix titles with the epic’s name: “Returns: prepaid label by email”. Any tool can search for it.
• A label, tag or category set to the epic’s name, so a filter shows the whole group.
• Links between related items, so the person on the refund story can find the label story.
• The epic’s one-pager kept as a note or document the group points to, rather than as a card that sits in a column for months.

What you lose is roll-up: a bar that says the epic is 60% done. Since that bar counts closed stories rather than the outcome, many teams find they do not miss it.

Doing it on fenbs

fenbs has no epics and no sub-tasks, by design. Every task is a feature, an enhancement or a bug, in one of four lanes: To Do, Next Up, In Progress, Completed. The grouping comes from fields it does have: each task belongs to a project, can carry an optional category (set it to “Returns” and filter the board by it), and can be linked to related tasks. A task’s size runs from XS to XL, and XL means too big: split it, which is the epic question asked at the right moment. Write the epic’s outcome and scope as the note of the first task, or in the board’s AI context if an assistant will be cutting the stories.

To load the stories, paste them into Add many. A leading feature:, enhancement: or bug: sets each line’s kind, and you see a preview before anything is created.

feature: Returns: choose an item from a past order to return
feature: Returns: pick a return reason from a short list
feature: Returns: email a prepaid label
enhancement: Returns: reprint the label from the order page
feature: Returns: refund to the original card after the warehouse scan

If your organization needs several levels with progress rolled up across teams, a tool built around that hierarchy will serve you better, and that is a fair reason to use one.