Epics, Features, Tasks

Levels are about horizons

Every tracker ships a hierarchy — epic, feature, story, task — and most teams learn it as a filing rule: big things go in epics, small things go in tasks. That description is true and useless, because it does not tell you 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. If a level is not answering anyone's question, it is overhead — and a team with four levels where two would do spends its refinement sessions maintaining a tree instead of understanding the work.

What each level is for

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 — and it 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.

The same word, three different sizes

There is no standard behind these names. They come from tools and from SAFe, and each defines them differently — which is why two people can agree that something "is an epic" and be picturing work that differs by a factor of ten. Before arguing about a level, check whose vocabulary the other person is using.

One distinction from SAFe is worth borrowing regardless of the vocabulary you use: business versus enabler. A business item delivers value a user can see. An enabler builds the thing that makes future business items possible — infrastructure, an architectural change, compliance work, or research. Naming enablers explicitly is what stops technical work being disguised as a user story, and gives it a legitimate way to compete for capacity instead of hiding inside estimates.

How many levels do you need?

• 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 thing.

• A programme

  Four or five, with a portfolio level. Only add one when a real audience is asking 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 can be described twice and drift 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?".

Where the boundaries actually fall

Two practical tests settle most arguments about which level something belongs to.

• 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 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.

A useful consequence of the audience test: tasks do not need estimating, grooming or a polished description. Time spent making the task level presentable is time taken from the levels someone actually reads.

An epic needs a hypothesis and an exit

An epic is a bet, and a bet you cannot lose is not a bet. Writing one properly takes two sentences: what you believe will happen, stated so that it could turn out false, and the condition under which the epic is closed. "We believe letting customers save a basket will raise week-2 return visits from 18% to 25%; we will close this epic when saved baskets are live for all users and we have four weeks of data, whatever the data says."

The second half is what prevents the eternal epic. Without a stated closing condition an epic has no way to end, so anything vaguely related gets filed under it and it survives three reorganisations. With one, the leftovers at closing time have to justify themselves as a new bet — which most of them cannot.

Why rolled-up estimates mislead

Trackers will happily sum the points of every story under an epic and show you a number. The number is real arithmetic on unreal inputs, and it is worth understanding why before anyone plans a quarter on it.

The stories that exist today are the ones someone has already thought of. On a real epic, refinement keeps discovering more — so the total grows through the quarter even when nothing goes wrong, and the growth is largest exactly where the work was least understood. A rolled-up total therefore reads as a forecast while behaving as a lower bound.

The honest alternatives are both simple. Forecast from the count of completed items and how long they historically took, which at least uses measured data. Or size the epic directly at its own level — "roughly a quarter for one team" — and treat that as the bet it is, rather than laundering a guess through a sum that looks precise.

How this shows up in real delivery

The clearest symptom of a broken hierarchy is the eternal epic — one that has been open for three quarters, collects anything vaguely related, and has no definition of finished. It is no longer a bet with a horizon; it has become a folder. The fix is not better hygiene, it is to give the epic a closing condition and let the leftovers become their own bet.

The second symptom is quieter: a hierarchy that is perfectly maintained and that nobody reads. If the epic list has not changed a single decision in a quarter — no reprioritisation, no cancellation, no conversation — then the levels are being kept for their own sake, and the refinement hours spent on them bought nothing.

Where it degrades

• Epics with no closing condition, which turn into permanent folders.
• A level added because the tool offers it rather than because someone asked a question.
• Two groups using the word "epic" at different scales without noticing.
• 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 prioritised openly.
• Estimating at every level, which multiplies the cost of being wrong without improving the forecast.

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 every story delivers something a user can actually use. This page covers the 3 Cs, acceptance criteria, six ways to split a story, story mapping, spikes and what points are for.
• ManagementWork Breakdown StructureA work breakdown structure (WBS) is a hierarchical breakdown of everything a project will deliver — and, by definition, nothing it will not. The WBS is a scope boundary drawn as a tree: if a piece of work is not somewhere in it, it is not in the project. This page covers the 100% rule, the WBS dictionary, control accounts, the numbering scheme and how deep to decompose.
• ManagementOKROKR — Objectives and Key Results — is one qualitative goal paired with a few measurable outcomes that prove it happened. OKRs are a goal-setting and alignment tool — the moment they become a task list or a performance rating, they stop working and usually get blamed for it. This page covers outcomes versus outputs, committed versus aspirational goals, the cadence, scoring and the difference from KPIs.