User Story vs Epic vs Task vs Bug: How the Pieces Fit

A user story describes a change from the point of view of the person who will use it, and why it matters to them. A task is one piece of the work the team does to deliver that change, small enough for one person to finish in a day or so. An epic is a story too big to deliver in one go, which gets split into stories. A bug is something that exists and does not work as intended; some teams order bugs alongside stories, others file them as tasks under the story that caused them. None of these words has one official definition, and usage varies between teams and tools. Below is the hierarchy as most teams draw it, how each piece is written, and a flatter scheme for teams that do not need the layers.

This page is about how the pieces relate. For the story format itself, see the user story template and user story examples; for writing a bug, see the bug report template.

The hierarchy as most teams draw it

From the biggest to the smallest, the layers you will usually meet are these. Not every team uses all six, and the names in the middle move around the most.

• Theme. A broad area of value, such as “self-service” or “reporting”. Themes group work rather than sit above it: the Agile Alliance notes that themes are typically not used as a level in a backlog hierarchy↗ (opens in a new tab), and describes an epic as a large user story that cannot be delivered as defined within a single iteration, or that is large enough to be split into smaller stories.
• Epic. A large outcome, such as “customers manage their own bookings”. It is a placeholder for an idea that will become several stories when the team is ready to work on it.
• Feature. Used in two ways. In some teams it is a layer between epic and story, a recognisable capability like “rescheduling”. In others it is just another word for an epic, or for any new capability. Pick one meaning and write it down.
• User story. A change a user would notice and value, small enough to finish within an iteration: “As a customer, I want to move my booking to another day, so that I do not have to cancel and rebook.”
• Task. A piece of the work that delivers a story: “Add the reschedule endpoint”, “Update the confirmation email”. Tasks are usually written by the people doing the work, and often only exist while the story is in progress.
• Subtask. A step inside a task, where a tool supports it. Many teams find a checklist inside the task does the same job.

Why usage varies

There is no standard that defines the whole ladder. The Scrum Guide↗ (opens in a new tab) mentions none of story, epic or task: it speaks of Product Backlog items, and says that Developers plan the work for each selected item, often by decomposing it into smaller work items of one day or less. That last phrase is the closest thing to an official definition of a task, and it does not use the word.

Other public sources size an epic differently. The GOV.UK Service Manual’s page on writing user stories↗ (opens in a new tab) says large stories, ones that would take more than a few weeks to develop and test, are typically called epics, and advises splitting them into stories that can be completed within an iteration. The Agile Alliance measures an epic against one iteration instead. Both are reasonable; what matters is that everyone on your team uses the same one.

Where bugs fit

Bugs are where hierarchies get awkward, because a bug is defined by its relationship to what already exists, not by its size. Three placements are common:

1. A bug is a backlog item beside stories, ordered with them. This suits bugs found in software already in use: they compete for the same time as new work, so they belong in the same ordered list.
2. A bug found while building a story is a task under that story. The story is not done until it is fixed, so it does not need its own place in the backlog.
3. Bugs live in a separate list. This is common and usually a mistake for a small team, for the reasons in tracking bugs and feature requests in one board.

Some trackers skip stories altogether and classify by type. Mozilla’s Bugzilla has three bug types↗ (opens in a new tab): defect, for regressions, crashes and other general issues; enhancement, for new features and other user-facing changes; and task, for refactoring and other engineering work. Everything is one flat list, sorted by type and priority.

How each one is written

The same product, a booking app, at every level:

Theme:    Self-service
Epic:     Customers manage their own bookings
Feature:  Rescheduling
Story:    As a customer, I want to move my booking to another day,
          so that I do not have to cancel and rebook.
          Done when: the new slot is held, the old one is freed,
          and a new confirmation email is sent.
Tasks:    Add the reschedule endpoint
          Show a "Move" button on upcoming bookings
          Send the updated confirmation email
Bug:      Moved booking keeps the old reminder time
          Steps: book Tue 10:00, move to Thu 14:00
          Expected: reminder Thu 13:00. Actual: reminder Tue 09:00.

• An epic is an outcome sentence and a rough boundary: what is in, what is out. Do not estimate it closely; it is too vague to estimate well until it is split.
• A story is who, what and why, plus acceptance criteria. The Agile Alliance’s three Cs↗ (opens in a new tab) are a good reminder of what it really is: a card, the conversation about it, and the confirmation that it works. The criteria are covered in acceptance criteria examples.
• A task starts with a verb, names one piece of work, and is small enough that its owner can say “done” by tomorrow. It rarely needs a “so that”, because its story already says why.
• A bug is steps, expected and actual, and how bad it is. Writing a bug as a story (“As a customer, I want reminders to be right”) hides the steps inside a sentence.

Story or task? Four questions that settle it

1. If only this piece were done, would a user notice anything? If yes, it is a story. If no, it is a task inside one.
2. Does something that already exists fail to do what it was meant to? Then it is a bug, whatever size it is.
3. Would it take longer than one iteration, or does it clearly contain several things a user would notice separately? Then it is an epic, and it needs splitting before anyone starts.
4. Can one person finish it in a day or so, and check it themselves? Then it is a task. If it takes a week, it is probably a story, or several tasks.

A common failure is a “story” that is really a task in disguise: “As a developer, I want a reschedule endpoint.” Nobody outside the team would notice it on its own. Either fold it into the story it serves, or write it plainly as a task.

A simpler alternative: three kinds, one level

The ladder earns its keep in large organisations where several teams roll work up to a shared plan. A small team often spends more time deciding which layer something belongs in than doing it. The alternative is to drop the layers and classify every piece of work by one question: is it new, a change to something that exists, or something broken?

• Feature: something that does not exist yet. Most stories are features.
• Enhancement: something that exists and works, and should be better. Many small stories are enhancements.
• Bug: something that exists and does not work as it should.

Epics become a label that groups related work, and tasks become either a checklist in the story’s plan, when one person does all of it, or items of their own, when different people pick up different parts. Colour-coding by kind is an old idea: the Agile Alliance’s entry on the task board↗ (opens in a new tab) mentions colours used to tell features from bug fixes. Why three kinds are enough is argued in features, enhancements and bugs, and the edge cases are decided in feature, enhancement or bug.

On a fenbs board, honestly

fenbs uses the flat scheme and does not pretend otherwise. There are no epics, no sub-tasks, no sprints and no story points. Every task has one of three kinds, feature, enhancement or bug, and sits in one of four lanes: To Do, Next Up, In Progress, Completed.

• In place of epics: optional projects and categories group tasks, and a task can be linked to related tasks, so the pieces of one larger idea can be found together.
• In place of a story’s sub-tasks: the plan box holds how the work will be done, step by step, and is rewritten as people learn. If a step belongs to someone else, make it its own task and link the two.
• A size from XS to XL, where XL means too big: split it. That is the one place the board asks the epic question.
• Priority from 1 to 10, 1 the most urgent, for stories and bugs alike, so they are ordered in one list.

If your organisation needs a hierarchy with roll-up reporting across several teams, a tool built for that will serve you better. If you mainly need to know what is next and who is doing it, one level is usually enough.