Epic vs User Story vs Task: How to Break Work Down Without Losing the Thread

An epic is a large piece of work that delivers one outcome and gets split before it is built. A user story is a single change described from the point of view of somebody who uses the product. A task is a unit of execution with no user in it. They differ by scope and by whose language they use.

That is the whole answer. The reason the question keeps being asked is that the words are not defined by any standard, and the tools most teams use have quietly redefined them. This piece covers the three levels, where the boundaries actually sit, and why your Jira board disagrees with the book you read.

What is the difference between an epic, a user story and a task?

Scope and audience separate them. An epic covers an outcome too large to finish in one pass, a user story covers one observable change for a user, and a task covers one piece of work an engineer picks up and completes.

	Epic	User story	Task
What it is	An outcome that needs splitting before it can be built	One change stated from a user’s point of view	One piece of execution
Typical size	Weeks to a few months, several people	A few days, one or two people	Hours to a day
Whose language	Product and stakeholders	The user’s	The engineer’s
Usual shape	A goal plus the stories that satisfy it	”As a [role], I want [change], so that [reason]“	An instruction: “Add an index on orders.created_at”
Estimated	Rarely, and only in ranges	At refinement, in points or days	In hours, if at all
Done when	Every story under it is done and the outcome is visible	Its acceptance criteria pass	The work is finished
Who reads it	Anyone asking what the team is doing this quarter	The team, plus anyone reviewing scope	Whoever picks it up

Read that downward rather than across. The rows that decide the level are size and language: a ticket written in the user’s words is a story, a ticket written in the team’s words is a task, and a ticket that needs several of either is an epic.

One caveat before anyone quotes this at a colleague. None of these three terms appears in the Scrum Guide, which talks only about Product Backlog items. Epic and user story come from Extreme Programming and from Mike Cohn’s writing on stories, and everything since has been convention. Where the convention is contested, the team’s agreement beats the definition. For the writing itself, there is a real craft to phrasing stories and tickets engineers can act on, and it is a separate skill from choosing the level.

Is an epic the same as a user story?

No, but it started as one. In the original usage an epic was just a user story too large to build in one go, which would be split before the team committed to it. It described size, not a rung on a ladder.

Two things happened after that. Tools turned the epic into a container with its own issue type, and teams started creating epics up front as planning artefacts rather than discovering them as stories that had grown too fat. Both are workable. Neither matches the original meaning, which is why one person on your team insists an epic is “a big story” and another insists it is “a folder of stories”. They are both quoting something true.

The practical test is whether the epic names an outcome. “Two-factor authentication” is a subject. “Customers can secure their account with two-factor authentication” is an outcome, and you can tell when it is done. An epic that has been open for eight months is not an epic. It is a category with a burndown chart attached.

What is the difference between a user story and a task?

A user story describes something a person outside the team can notice; a task describes work. That is the whole boundary, and it is more useful than any size rule, because plenty of tasks take longer than plenty of stories.

The test that settles most arguments: name the person who is better off when this is done. If you can name them and say what changed for them, it is a story. If the honest answer is “the team” or “the codebase”, it is a task.

Some work should never be a story. Upgrading Postgres, rotating an expiring certificate, removing a dead feature flag, cutting the build time in half. Forcing those into “As a developer, I want a faster pipeline, so that I can ship faster” produces a sentence nobody believes and acceptance criteria nobody can test. Write them as tasks, put them in the same sprint, and let them compete for capacity honestly rather than in disguise.

The reverse mistake is quieter. A story that decomposes into exactly one task was always a task, and wrapping it in story ceremony costs a refinement slot and an estimate for no gain.

How Jira’s issue types changed what these words mean

Most of the confusion is a tooling artefact rather than a disagreement about definitions. Jira ships with a default hierarchy where subtasks sit at the bottom, Story, Task and Bug all sit together on the level above, and Epic sits above those. So in Jira, a task is not a smaller unit of a story. It is a peer of a story, at exactly the same level, with no user in it.

Teams who learned the vocabulary from the tool rather than from the practice end up with a hierarchy that reads Epic, Story, Subtask, and a floating population of Tasks nobody is sure how to nest. That is not a mistake on their part. It is what the software told them.

Other tools tell them something different:

• Jira: Epic contains Story, Task and Bug; those contain Subtasks. Higher levels such as initiative exist only on the paid tiers.
• Azure DevOps (Agile template): Epic contains Feature, Feature contains User Story, User Story contains Task. Here a task really is a child of a story.
• Linear: no epic at all. Projects contain issues, and issues have sub-issues.

Three tools, three shapes, one vocabulary. The lesson is not that one of them is right. It is that “epic” means whatever level your tool calls an epic, so pin that down once for your team and stop relitigating the word. If you are setting the structure up from scratch, the choices about hierarchy, views and grouping are worth making deliberately.

One epic, broken down

Here is the shape in practice, using two-factor authentication on a business application.

Epic: Customers can secure their account with two-factor authentication.

Stories under it, each with a user who notices:

• As an account owner, I can enable app-based two-factor authentication on my account.
• As an account owner, I can generate and download recovery codes.
• As a user with two-factor enabled, I am prompted for a code when I sign in from a new device.
• As an admin, I can require two-factor authentication for everyone in my organisation.
• As a user who has lost their device, I can regain access through support.

Tasks in the same sprint, with no user in them:

• Add TOTP secret storage with encryption at rest.
• Add rate limiting to the verification endpoint.
• Write the runbook for support-assisted account recovery.

Notice what the split reveals. The support recovery path is a story, not a footnote, and the person who spots that is usually the one asked to staff the support rota. The sizing rules for that split, and the limits on how far to take it, are covered in more depth in breaking an epic into user stories.

Where that split gets argued matters. Done as a quiet edit in the backlog, it gets reopened every sprint; done with the engineers who will take the stories, it gets decided once. Projan runs it as a structured conversation in Slack, asking what would still be missing if each story shipped on its own, then writing the agreed epic and its stories out to Jira or Linear.

Five signs the hierarchy has stopped working

The levels are meant to make work legible. When they stop doing that, the symptoms are consistent.

1. Epics that never close. A permanent epic called “Platform” or “Tech debt” is a label. Nothing under it is ever the last thing.
2. Stories written for the team. “As a developer, I want a caching layer” is a task in costume. It signals that the team believes only stories get scheduled.
3. Subtask trees that need their own standup. If a story has fourteen subtasks and the parent tells you nothing, the story was an epic.
4. Estimated epics. Pointing an epic means committing to a number before the work has been split, which is the guess you were trying to avoid.
5. Bugs promoted to epics for visibility. When severity gets expressed through issue type, the hierarchy has become a political instrument and the board has stopped describing the work.

None of these is fatal on its own. Two or more at once usually means the backlog is being maintained for a reporting view rather than for the people building from it.

Frequently asked questions

What sits above an epic? Nothing standard. Many teams put an initiative or a theme above the epic to group several epics under one business goal, and Jira offers that level on its higher tiers. Some organisations add a portfolio level above that. None of it is defined by Scrum, so the number of levels above an epic is a local decision rather than a rule.

Is a bug a user story or a task? Neither, in most tools. Jira and Azure DevOps both give bugs their own issue type sitting alongside stories, because a bug describes broken behaviour rather than new behaviour. Treat a small bug as a task the team just does, and a large one as a story with acceptance criteria, since a fix nobody can verify tends to come back.

Should a spike be a story or a task? A task, usually, with a fixed time box and a named output. A spike is investigation, so it has no user-facing outcome and no acceptance criteria worth writing. Give it a question to answer, a deadline and a place to write the answer down. Spikes that produce no artefact are the easiest work in the backlog to repeat by accident.

Can a user story exist without an epic? Yes, and most should. Small independent changes do not need a parent, and forcing one produces epics that exist only to hold unrelated tickets. Create an epic when several stories together deliver an outcome that none of them delivers alone. If you cannot say what that shared outcome is, you are describing a label, not an epic.

Does any of this matter if the team ships anyway? It matters at the boundaries of the team. Levels exist so people outside the sprint can see what is being worked on without reading forty tickets. If your stakeholders never look at the backlog and the team plans well without the structure, keep it thin. The cost of a hierarchy is the effort of maintaining it.

Size and audience are the only two variables that matter here, and everything else is your tool’s opinion. Agree what each level means once, write it down where new joiners will find it, and spend the argument budget on scope instead. Who writes what at each level is a separate question, answered in who writes user stories.