Epics, Features, Tasks

Every level on one screen — and one epic taken down to tasks

People who look this up usually want two things: what each word means, and what a real one looks like. Here are both. First the levels, each with its size, the person who decides and the condition that ends it. Then one epic for the online shop from the WBSWBSWork Breakdown Structure — the project’s scope as a treeA tree of everything a project will deliver, broken down until each piece is small enough to estimate and give to one owner — and, by definition, nothing the project will not deliver. Its children must add up to exactly their parent, which is what makes it a scope boundary rather than a task list.Full article →All terms page, a year after launch, taken all the way down to the tasks for one story. Later sections cite its lines by number.

1. 1.Feature 1 — Reorder from order history

   1. 1.1A returning customer sees past orders, newest first, each with a Reorder button
   2. 1.2Reorder puts every item that is still in stock into the cart
   3. 1.3An item out of stock is named, and a substitute is offered
   4. 1.4A price that changed since the last order is shown before payment

2. 2.Feature 2 — Saved baskets

   1. 2.1Save the current cart under a name
   2. 2.2Open a saved basket and go straight to checkout
   3. 2.3Rename or delete a saved basket

3. 3.Feature 3 — Reorder reminders, only if the leading indicators move

   1. 3.1Opt in to a reminder when an item bought regularly is likely to run out
   2. 3.2The reminder email opens a cart that is already filled
   3. 3.3Unsubscribe in one click, from the email itself

4. 4.Enabler 4 — Order history service

   1. 4.1History for a customer with 500 orders returns in under 300 ms
   2. 4.2Orders migrated from the old shop are included — WBS line 5.2
   3. 4.3SpikeSpiketime-boxed researchA deliberately time-boxed piece of research whose output is an answer, not a feature. The time box is the whole point: a spike without one becomes an open-ended investigation that quietly consumes a sprint.Full article →All terms, two days: can the ERP report stock per item in real time? Output: a written yes or no

Tasks exist for exactly one story: 1.2, the one in the current sprint. The team wrote them at sprint planning, in about ten minutes. They are the team’s plan, so they are not numbered with the rest:

• An endpoint that copies an order’s lines into the cart.
• A stock check for each line, built on the answer to spike 4.3.
• A merge rule for a cart that is not empty: add, do not replace.
• Automated tests for the story’s three acceptance criteriaacceptance criteriahow this story will be judged doneThe conditions one piece of work must meet to be accepted, agreed before it is built — for example, that an expired promo code is rejected with its expiry date. They differ from a Definition of Done, which applies to every piece of work; fifteen of them on one story usually means it is several stories.Full article →All terms.
• An event for the dashboard that counts repeat orders started from Reorder.

Where the words come from — and why “epic” has three sizes

No standard defines these levels. The Scrum Guide, which many teams assume is the source, uses none of the three words. It has one kind of item, the Product BacklogBacklogthe ordered list of what is leftThe ordered list of everything that might be built, with the most valuable at the top. Ordered is the operative word: a backlog where everything is equally important is a wish list, and it makes no decision easier.Full article →All terms item. Of the plan inside a sprint it says only that this “is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers.” Everything above that item and below it is convention.

The conventions come from three places. Extreme ProgrammingExtreme Programmingthe engineering-first agile methodAn agile methodology from the late 1990s built around engineering practices: test-first development, pair programming, continuous integration, refactoring and small, frequent releases. Much of what teams now call technical agility comes from it, and a team that adopts Scrum’s events without these practices usually watches its sprints slow down.All terms gave teams stories and the tasks under them. Mike Cohn’s books spread “epic” as a name for a story too big for one iteration — in his own words, there is “no magic threshold”. Dean Leffingwell’s books put epics above features above stories, and in 2011 that became the requirements model of SAFeSAFeScaled Agile Framework — a framework for running many agile teams as oneThe Scaled Agile Framework: roles, events and practices for coordinating dozens of agile teams, built around the Agile Release Train — five to twelve teams that plan together every eight to twelve weeks. It is the most prescriptive and the most widely adopted scaling framework, which is also why it can be installed without changing who makes the decisions.Full article →All terms. The trackers then each shipped one of these shapes, and the shape a team uses is usually the one its tool came with.

Renaming does not change the shape. Since 2025 Jira’s interface says “work item” where it used to say “issue”, and since October 2025 a project is a “space”. The hierarchy underneath is the same three levels. When two people disagree about whether something is an epic, the useful question is therefore not the definition but the horizon: how many sprints will it span, and who decides whether it continues?

What each level is for — and how many you need

Most teams learn the hierarchy as a filing rule: big things go in epics, small things go in tasks. That description is true and useless, because it does not say where to draw the line, and “big” is not a property anyone can check.

The useful rule is that each level answers a question for a different person, over a different horizon. A horizon is how far ahead that person plans. A level that answers nobody’s question is overhead, and a team with four levels where two would do spends its refinement maintaining a tree instead of understanding the work.

Read the right-hand column downward. The decision moves from leadership to one engineer, and the horizon shrinks from quarters to hours. That is the whole logic of the hierarchy. It also explains why an epic owned by a developer, or a task tracked by a director, is a sign that a level has lost its purpose.

How many levels to keep

• One team

  Two levels: story and task. An epic adds nothing when one Product Owner holds the whole picture in their head.

• A few teams

  Three: epic, story, task. The epic is where teams see that they are working on the same bet.

• A programme

  Four or five, with a portfolio level. Add one only when a real audience asks a question the level below cannot answer.

The default should be fewer. Every level costs refinement time, needs its status kept honest, and creates one more place where the same work is described twice and drifts out of sync. The test for adding one is not “would this be tidier?” but “who is asking a question today that they cannot answer, and would this level answer it?”.

Two tests for where an item belongs

• The release test

  If shipping it alone would make sense to a user, it is a story. If it only makes sense once several pieces are out, it is a feature or an epic.

• The audience test

  If nobody outside the team will ever read it, it is a task. Tasks are the team’s working notes, not a reporting layer.

Run both on the epic above. Line 1.2 alone makes sense to a customer, so it is a story. Feature 2 makes sense only once 2.1 and 2.2 are out — a basket you can save but never open is useless — so it is a feature. And the five tasks under 1.2 will never be read by anyone outside the team, so nobody should estimate, groom or report on them.

Writing an epic: a hypothesis, an MVP and an exit

An epic is a bet, and a bet you cannot lose is not a bet. Writing one properly takes three things: what you believe will happen, stated so that it could turn out false; the smallest thing you can build to find out; and the condition under which the epic ends. SAFe gives the first a template, the epic hypothesis statement, and it is worth borrowing whatever vocabulary you use. Here it is, filled in for the epic above.

The row that does the most work is the leading indicators. A business outcome like return visits takes a quarter to show and is moved by many things at once. A leading indicatorleading indicatoran early, imperfect signalA metric that moves early and predicts a later result imperfectly — how many customers use a new feature in its first weeks, as a signal of next quarter’s retention. Its opposite, a lagging indicator such as revenue, is accurate but arrives too late to act on.Full article →All terms moves within weeks and predicts the outcome imperfectly: if almost nobody starts a repeat order from the Reorder button, return visits are not going to rise because of it. Without leading indicators, the decision whether to continue can only be taken after the money is spent.

The MVP, and the decision it exists for

An MVP, a minimum viable product, is the smallest version that can prove or disprove the hypothesis. SAFe requires one for every epic. It moves epics across a portfolio Kanban board: funnel, reviewing, analysing, ready, implementing the MVP, implementing beyond it, done. Work on the MVP stops when the money set aside for it is spent or the hypothesis is proven or disproven — whichever comes first. Only a proven hypothesis earns the rest of the features.

In the epic above the MVP is feature 1 alone, for one customer in five, for four weeks. If the leading indicators move, the team perseveres: feature 2, then the rollout to everyone. If they do not, the epic stops, and the three features nobody built are the saving. A third exit is the pivot: the data shows a different bet worth making — say, customers reorder from the confirmation email, not from history — and that bet enters the funnel as a new epic with its own hypothesis.

The closing condition

The closing condition is what prevents the eternal epic. Without one an epic has no way to end, so anything vaguely related gets filed under it, and it survives three reorganisations. With one, whatever is left at closing time has to justify itself as a new bet — which most leftovers cannot. The condition above says “whatever the data says” on purpose: an epic closed only on success stays open for as long as somebody hopes.

Below the epic: features, enablers, bugs, spikes and tasks

A feature is a part of an epic that is useful once it ships as a whole. SAFe defines it as functionality “sized to be delivered by an Agile Release TrainAgile Release Train5–12 teams that plan and deliver togetherIn SAFe, a long-lived group of five to twelve agile teams, usually 50 to 125 people, that plan together at PI Planning, work to the same iteration boundaries and integrate their work every iteration. It should be drawn around the path a product takes to its customers; a train drawn around the existing departments coordinates them without changing anything.Full article →All terms within a PI” — a planning interval of eight to twelve weeks — and gives each one a benefit hypothesis and acceptance criteria. Outside SAFe the useful size is a few weeks. The feature level earns its place when several stories only make sense together, as 2.1 to 2.3 do; when every feature holds a single story, the level is empty and should go.

Enablers: naming the work no user asked for

An enabler is a backlog item that delivers no visible value itself and makes later items possible. SAFe defines enablers as items that “extend the architectural runway of the solution under development or improve the performance of the development value stream”, and they can sit at any level: an enabler epic, feature or story. Naming them is what stops technical work being disguised as a user storyuser storya need told from the user’s sideA short description of something a user needs and why, usually "As a …, I want …, so that …", written as a promise of a conversation rather than a specification. Its weakness is its strength: without acceptance criteria agreed in that conversation, two people will build two different things from one card.Full article →All terms, and gives it a legitimate way to compete for capacity.

Tools carry the same distinction under other names. Since May 2015, when the service was still called Visual Studio Online, Azure DevOps has had a Value Area field on its work items — Business or Architectural — added together with its Epic level to support SAFe. In Jira the convention is a label or a separate work type. What matters is not the field but the agreement that comes with it: a fixed share of each sprint’s capacity set aside for enablers, so that they are prioritised openly instead of squeezed out by features. A fifth is a common starting point.

Bugs and spikes

A bug is not a story. Jira puts it at the story level, as a sibling rather than a child, because it competes for the same sprint capacity; Azure DevOps lets each team choose whether bugs sit with stories or with tasks. Writing a bug as a story — “as a customer, I want the total to be correct” — inflates the count of value delivered. A spike is a time-boxed enabler story with one question and a written answer, like line 4.3. Without the time box and the question it becomes a side project.

Tasks: the team’s plan, not a reporting layer

Tasks are the oldest level here. In Extreme Programming the programmers broke each story into tasks at iteration planning, signed up for them and estimated their own, at one to three ideal days each. The Scrum Guide keeps the substance and drops the word: work items of a day or less, decomposed “at the sole discretion of the Developers”. Both say the same thing — the task level belongs to the people doing the work, and its job is to make tomorrow’s plan visible to the team.

Why rolled-up estimates mislead — and what to forecast with

Trackers will happily add up the points of every story under an epic and show you a number. The number is real arithmetic on unreal inputs. The stories that exist on day one are the ones someone has already thought of. On a real epic, refinement keeps finding more — the out-of-stock path, the price change, the migrated orders — so the total grows through the quarter even when nothing goes wrong, and it grows most where the work was least understood.

A rolled-up total therefore reads as a forecast while behaving as a lower bound. Divide it by velocity and you get a date that is reached only if nobody learns anything for a quarter. The chart above is illustrative, but its shape is the normal one: the done line and the scope line both rise, and the gap closes far later than the day-one total implied.

Five episodes that put the words where they are

The hierarchy has no single failure to point at. It drifts slowly, and the drift is documented by the people and companies that caused it. Each of these five left something behind that teams still trip over.

Read the table as a sizing story. Extreme Programming had no epics at all; its unit of planning was the story, and the task was the programmer’s own business. Cohn’s epic was a story that had not been split yet — a few weeks of work, waiting for refinement. Leffingwell’s epic was a different object that happened to share the name: a portfolio decision, measured in quarters and money, with features and stories underneath. From then on, the word meant whatever the tool in front of you meant.

The tools then fixed the two meanings in place. Microsoft built its Epic level in 2015 explicitly for SAFe, so an Azure DevOps epic sits above a feature and is sized like a portfolio item. Jira kept the epic as the top of a three-level stack, so in most Jira projects it absorbs everything from a fortnight to a year. A team that moves from one tool to the other, or merges with a team on the other, inherits the confusion without anyone deciding anything.

Where it degrades

A work hierarchy rarely fails loudly. It fails as a tree that is perfectly maintained and changes no decision. Almost every such failure is one of these:

• Epics with no closing condition, which turn into permanent folders that survive three reorganisations.
• Epics with no hypothesis, so there is nothing an MVP could disprove and every epic is built in full.
• A level added because the tool offers it rather than because someone asked a question.
• Two groups using the word “epic” at different sizes without noticing.
• Features that hold one story each, so the level is pure overhead.
• Stories that are really tasks, so the sprint fills with work no user will notice.
• Technical work disguised as user stories instead of being named as enablers and given capacity openly.
• Subtasks per discipline, which bring back the hand-offs and report progress that is not there.
• Tasks written months ahead, or estimated and reported on as if they were a level for stakeholders.
• Points rolled up the tree and divided by velocity, which turns a lower bound into a promised date.

The honest limit is that a hierarchy can make a bet visible and its size legible; it cannot make the bet good. A perfectly kept tree, every epic with a hypothesis, an MVP and a closing condition, will still contain wrong bets. That is not a defect. The point of the structure is that a wrong bet ends at its MVP, for the price of its MVP, instead of at the end of the year for the price of everything.

The practical check takes an hour. Open every epic and look for a hypothesis that could be false and a closing condition; note how long each has been open. Count the levels and ask who reads each one. Look for features with one story and for subtasks named after disciplines. Find out where any date quoted to a sponsor came from — if the answer is a sum of points, replace it with a range from finished items.

When to use it

Related pages

• ManagementUser StoriesA user story is a short description of a need from the user’s point of view, written to start a conversation rather than to replace one. The template is the least important part; the skill is slicing work so that every story gives a user something they can actually use, and agreeing before the work starts how everyone will know it is done. The page opens with sixteen stories as teams actually write them, what is wrong with each and the rewrite, then covers card, conversation and confirmation, acceptance criteria and example mapping, nine ways to split a story, story mapping, INVEST, spikes and points, five episodes from the format’s history, and where it degrades.
• ManagementWork Breakdown StructureA work breakdown structure (WBS) is a hierarchical breakdown of everything a project will deliver — and, by definition, nothing it will not. It is a scope boundary drawn as a tree: if a piece of work is not somewhere in it, it is not in the project, and adding it is a change rather than an edit. The page opens with a finished WBS for an IT project — eight branches, thirty-one work packages, coded and adding up to 100% — then covers the rules that make a tree a WBS, the dictionary where scope actually lives, codes and control accounts, how deep to decompose, the WBS beside an agile backlog, three documented cases, and where it degrades.
• ManagementOKROKR — Objectives and Key Results — is a goal-setting method that pairs one qualitative objective with two to five measurable results proving it was reached. It came from Intel in the 1970s and reached Google in 1999, and it works only when key results measure outcomes rather than tasks, when committed and aspirational goals are scored by different rules, and when scores stay out of pay. The page opens with one team’s OKRs for a quarter, finished, then covers what Grove, Doerr and Google actually wrote, outcomes and guardrails, how a score is computed, alignment and the weekly cycle, OKR beside KPI and pay, four cases and where it degrades.