Epic vs story vs task: the agile hierarchy explained
Epics, stories and tasks are three tiers with three jobs. What each is, which one carries story points, and why pointing the wrong tier makes velocity meaningless.
Most agile tools — Jira, Azure DevOps, Linear — ship three tiers: epics, stories, tasks. The hierarchy is load-bearing only if each tier means something distinct. When teams point all three the same way, the tiers collapse and the planning signal goes with them.
Epic
A body of work bigger than a sprint — usually a feature or initiative the team delivers across several sprints. Epics are sized in t-shirt sizes, weeks, or story counts (how many stories you think it’ll decompose into), not story points directly. A point number at the epic level is an aggregation of the underlying stories, not a direct estimate.
Story
A user-facing slice of work that fits in one sprint. Stories are what planning poker estimates, and where story points live. The story is the unit of velocity, and the unit of “what we’ll commit to this sprint.” If a story won’t fit a sprint, it’s really an epic — split it into stories that will.
Task
A child of a story — a checklist item, a piece of implementation. Tasks are typically sized in hours or not sized at all. Pointing tasks duplicates the story’s points and makes velocity meaningless, because you end up counting the same effort twice, at two levels of abstraction.
The trap: pointing every tier
Some Jira workflows encourage pointing tasks under stories; some tools push for pointing epics. Both habits produce velocity numbers that don’t correspond to anything real, because effort is being counted at multiple levels. Pick one tier — the story — and only point there. Everything above it is an aggregation and everything below it is implementation detail; neither should feed the velocity number directly.
Frequently asked questions
What is the difference between an epic, a story and a task?
An epic is a large body of work that spans multiple sprints, a story is a user-facing slice that fits in one sprint, and a task is a technical step that helps complete a story. Roughly: an epic says what and why at scale, a story says what and why for the user, and a task says how to build it.
When does a story become an epic?
When it won’t fit in a single sprint. If the team can’t deliver it end to end in one sprint, it’s really an epic and should be split into several stories that each can. A story that keeps growing in refinement is usually an epic in disguise.
Should you estimate epics in story points?
Not directly. Size epics in t-shirt sizes, rough story counts, or as the sum of their underlying stories once they’re broken down. A point number on an epic is an aggregation, not an estimate — the real sizing happens at the story level.
Do tasks get story points?
No. Tasks are sized in hours or left unsized. Pointing tasks under a story double-counts effort — you end up counting the same work at two levels — which makes velocity meaningless. Point the story, not its tasks.
Related reading
- What are story points? — the unit that lives at the story tier.
- Splitting user stories — what to do when a “story” is really an epic.
- Velocity — why counting effort at more than one tier breaks the forecast.
- Agile estimation guide — the full estimation cluster.
- Free planning poker for agile teams — estimate stories with your team in real time.