Open almost any team's backlog and you'll find the same quiet mess. Some work is filed as an Epic because it felt big at the time. Some is a Story because someone read that stories are the "right" unit. Half the Tasks should be subtasks of something, and a third of the Epics have been "in progress" for four months because nobody agreed on what finishing one even means. The types are all there. What's missing is a shared rule for which type a piece of work is — so every person picks by feel, and the hierarchy stops meaning anything.
That's the real cost of a fuzzy issue hierarchy. It isn't that the wrong label offends a methodology; it's that reports, filters and sprint planning all read the type field and quietly produce garbage when it's inconsistent. An Epic that's secretly a single task inflates your scope. A Story split into eight subtasks nobody closes drags your velocity. The structure was supposed to make work legible, and instead it's one more thing to argue about.
This post is a working definition of each level — what it's for, not what a framework says it is — and a simple rule for how deep to nest before the structure costs more than it saves.
What each level is actually for
Forget the ceremony. Issue types answer one practical question: at what altitude are we talking about this work? Each level is a different zoom, and the whole point is that you can move between them without losing the thread.
- Epic — a body of work too big for one sprint, with a clear outcome. "Checkout redesign," "SOC 2 readiness," "migrate billing off the legacy provider." An epic is a promise to a stakeholder, not a task. You should be able to say when it's done in one sentence, and that sentence should be about user or business value, not about code.
- Story — a slice of an epic that delivers something on its own, sized to fit comfortably in a sprint. The test is independence: could you ship this and have a user notice, even a little? "Guest checkout" is a story. "Add a column to the orders table" is not — that's a step, not a slice.
- Task — a concrete unit of execution, usually one person, usually a few days at most. Tasks don't have to deliver user-visible value; they're the how. Not every task needs a parent story — plenty of real work (a flaky-test fix, a dependency bump) is just a task, and forcing a fake epic over it is its own kind of mess.
- Subtask — a checklist item that happens to need its own owner or status. Use it when a task genuinely splits across people or days ("backend endpoint" / "frontend wiring" / "migration"). If a subtask is really just a to-do, a checklist inside the task is lighter and won't clutter the board.
Here's the same idea as a quick reference:
| Type | Answers | Typical lifespan | Owned by |
|---|---|---|---|
| Epic | Why are we doing this? | Multiple sprints | Lead / PM |
| Story | What does the user get? | One sprint | The team |
| Task | What has to be built? | Days | One person |
| Subtask | Which piece of this task? | Hours to a day | One person |
In Issues & Boards these are the actual types you assign — Bug, Task, Story, Epic and Subtask — and every board, filter and report reads that field. That's exactly why picking the right one matters: it's not decoration, it's the key the rest of the tool sorts on.
The two failure modes: everything-is-an-epic and nested-to-oblivion
Teams break their hierarchy in one of two opposite directions.
The first is inflation — every meaningful piece of work becomes an epic because it feels important. Now your epic list is forty items long, half of them are really single tasks, and the one view that's supposed to show leadership the shape of the quarter is unreadable. Epics should be rare. If you have more open epics than engineers, they've stopped meaning "big theme" and started meaning "thing I care about."
The second is over-nesting — epic → story → task → subtask → sub-subtask by convention, whether or not the work needs it. A one-line copy fix does not need three ancestors. Every layer you add is a layer someone has to create, link, update and close; deep trees look organized and feel like progress, but mostly they generate status-keeping busywork and a board where nothing is ever quite done because some leaf three levels down is still open.
A rule that holds up well: add a level only when the work actually spans it.
- Default everything to a Task. Most work is a task. Start there.
- Promote to a Story when the task clearly delivers user-visible value and you want it to earn a line in the sprint on its own.
- Wrap Stories in an Epic only when several of them share one outcome you're reporting on to someone outside the team.
- Add Subtasks only when a single task genuinely needs more than one owner or spans more than a day.
If you can't name the thing that lives at a level, that level shouldn't exist for this piece of work. Two well-chosen types beat five reflexive ones every time.
Make "done" mean the same thing at every level
A hierarchy is only as trustworthy as its definition of finished, and each level needs its own.
- A subtask is done when its slice works and is merged.
- A task is done when it's built, reviewed and meets its acceptance criteria.
- A story is done when a user could actually use it — tested, shipped, not just code-complete.
- An epic is done when its outcome is real and you'd close it in front of the stakeholder who asked for it.
The trap is letting a parent auto-close when its children do, or worse, calling an epic "done" because the tasks are done while the outcome never shipped. Keep the parent's definition about the outcome, not the sum of its parts. This is also where a shared definition of done pays for itself: when everyone agrees what closing a story means, the board stops lying to your burndown.
Consistent types feed everything downstream. Clean epics make reports and cumulative-flow charts legible. Consistent stories make sprint planning honest, because a 30-minute plan only works when the units you're dragging in are actually comparable slices and not a random mix of themes and to-dos. Get the hierarchy right once and the rest of the tooling gets more accurate for free.
A five-minute audit for the backlog you already have
You don't need to reorganize everything. Spend five minutes and fix the ones that mislead:
- Find epics with no children or one child. Those are tasks wearing a costume. Demote them.
- Find stories older than two sprints. Either they were epics, or they're stuck — either way, split or close.
- Find deep subtask trees nobody closes. Collapse the dead ones into checklists.
- Agree on one sentence per level and pin it where people file issues. The definition living in your head is the reason everyone files differently.
Do this and the type field starts telling the truth again — which is the whole reason it exists.
Your issue types are only useful when everyone means the same thing by them. Issues & Boards gives you Bug, Task, Story, Epic and Subtask on drag-and-drop kanban and scrum boards, with swimlanes, WIP limits and quick filters reading a hierarchy you can actually trust. Start free and give your backlog a structure that ships.
