Epic, story, task and subtask compared
Most teams use a three- or four-level hierarchy. The names vary by tool, but each level answers a different question, from “what outcome are we after?” down to “what do I do next?”
- Epic: a large outcome or feature area, such as “Self-serve billing.” Too big for one sprint, so it usually spans several. It’s done when its goal is met, which is usually when its stories are done.
- Story: one slice of user value, such as “As an admin, I can download past invoices.” Written from the user’s point of view, small enough to finish in a sprint, and checked against acceptance criteria.
- Task: a concrete piece of work, such as “Add an invoices endpoint to the billing API.” Often technical and not visible to users on its own. Sized in hours or a day or two.
- Subtask: a step inside a story or task, such as “Write the migration for invoice PDFs.” Useful for splitting work between people or tracking progress, not for planning.
Where tasks fit: two common conventions
“Task” means different things depending on who you ask. In tools like Jira, a task is a sibling of a story: both sit under an epic, and the difference is framing. A story describes value for a user. A task describes work that needs doing but doesn’t map to a user outcome, like upgrading a dependency or rotating credentials.
In Scrum and Extreme Programming practice, tasks are often the breakdown of a story. During Sprint Planning, Developers split each selected item into pieces of a day or less, and those pieces live only for the sprint. Either convention works. Pick one, write it down, and use it consistently so boards and reports mean the same thing to everyone.
Epic vs feature vs user story
Some frameworks and tools add a level. In SAFe, epics break down into features, and features break down into stories. Other tools put initiatives or themes above epics to tie them to company goals.
If you add levels, give each one a distinct job. An epic answers “why are we investing here?” A feature answers “what capability will users get?” A story answers “what can we ship and demo this sprint?” If two levels answer the same question, merge them. Extra hierarchy adds overhead without adding clarity.
How to split an epic into stories
Split by user value, not by technical layer. A story that only creates a database table gives nobody anything to try. Slice vertically instead, so each story touches every layer it needs and ends in something you can demo. Common ways to slice:
- By workflow step: sign up, then verify email, then invite a teammate.
- By user role: the admin view first, the member view later.
- By business rule: flat-rate tax now, regional tax rules next.
- By data or platform: one payment method first, then the rest.
- By path: the happy path first, then errors and edge cases.
Who creates epics and stories
The product owner or product manager usually creates epics, because epics track outcomes and priorities. Engineering leads often shape them too, especially for technical work like a platform migration.
Stories are written by whoever understands the need best, then refined with the team. In Scrum, the Product Owner is accountable for the Product Backlog but can delegate the writing. Developers usually create tasks and subtasks themselves, since they know how the work breaks down.
Epic vs story in NoaBox
NoaBox has epic, story, task, bug and subtask work item types, each with a priority, labels, dates and one or more assignees. Attach a PRD (as a PDF or Markdown file), a spreadsheet or a CSV in Ask Noa and it drafts work items with priorities and acceptance criteria as proposals; nothing is created until someone confirms each one.
See boards and backlog