Epic, Story, Task: What They Mean and How to Tell Them Apart
Epic, Story and Task are three levels, not three sizes of one thing. A plain-language guide with one running example, a comparison and a rule of thumb.

If you have ever sat in a planning meeting, heard someone say "that's not a story, that's a task," and nodded without being quite sure why, you are in good company. Epic, Story and Task sound like three sizes of the same thing, so teams use them interchangeably, and the backlog slowly turns into a pile nobody can plan from.
They are not three sizes of one thing. They are three levels, and each has a different job. This is how I explain them to colleagues.
The hierarchy in one view
Think of a folder, a file, and a line inside the file. An Epic is delivered through several Stories, and each Story is built through a few Tasks. Throughout this post I will use one example: an organization replacing a paper-based permit request process with an online one.
One Epic, its Stories, and the Tasks under the first Story.
Epic: the big goal
In one line: a large goal that delivers business value and takes several sprints, or several weeks, to finish.
Who writes it: the product owner or a business lead, together with the people who feel the problem.
How long: several sprints or weeks.
Done when: the business goal is actually met, not just when the screens exist.
In our example the Epic is Online permit request: applicants can ask for a permit without paper.
Story: one piece of value
In one line: one piece of value, seen from the user's point of view. I like the classic format: As a [user], I want [goal], so that [benefit].
Who writes it: the product owner, refined together with the team.
How long: it fits inside one sprint.
Done when: its acceptance criteria pass. These are plain-language checks that tell you the story really works.
Our Epic has three Stories: submit a request online, track request status, and get notified when the status changes. The first one reads: As an applicant, I want to submit a permit request online, so that I do not have to bring paper forms to an office. Its acceptance criteria could be: a request cannot be sent without its required documents, and the applicant sees a confirmation afterwards.
Task: the work that makes it happen
In one line: a technical or operational work item needed to finish a story. On its own it has no value to the user.
Who writes it: the people doing the work, usually while planning the sprint.
How long: done by one person, usually hours to a day or two.
Done when: the work item itself is finished and checked.
Under "submit a request online" the tasks are: design the form, build the upload API, write the validation rules, and test with real documents. Nobody outside the team cares that an upload API exists. They only care that they can attach a document.
Epic vs. Story vs. Task at a glance
Size: an Epic is a large goal, a Story is one piece of user value, a Task is one work item.
Owner: the Epic belongs to the product owner or a business lead, the Story to the product owner with the team, the Task to the person doing it.
Time: an Epic takes several sprints or weeks, a Story fits within one sprint, a Task takes hours to a day or two.
Done when: the Epic's business goal is met, the Story's acceptance criteria pass, the Task is finished and checked.
Common mistakes
Tasks written as stories. "Build the upload API" has no user in it. If the user cannot see or care about it, it is a task.
Stories too big for one sprint. If it will not fit, it is probably an epic wearing a story's name. Split it.
Epics with no business goal. "Rebuild the database" is a pile of tasks. An epic should say what changes for the business or the user.
One huge epic that never closes. When every new idea goes into "Phase 2," you can never say what was delivered. Close epics and open new ones.
A rule of thumb
If the user can see and care about it, it is a story. If only the team cares, it is a task. If it takes several stories to deliver, it is an epic.
It is not perfect, but it settles most arguments in a planning meeting within a minute.
How does your team split its work? I would like to hear what works for you.


