Epics, Stories and Tasks: Structuring Agile Work

Epics and user stories are the two main levels most agile teams use to organise work. An epic is a large body of work that delivers a meaningful outcome and spans several sprints. A user story is a small, valuable slice of that epic that can be finished within one sprint. Tasks sit underneath stories and describe the technical steps to complete them.

Get the levels right and planning gets easier at every scale. Get them wrong and you end up with "epics" that take a day and "stories" that take a quarter.

The three levels

Epics

An epic describes an outcome big enough to need several sprints: "Customers can manage their subscriptions online". It is how stakeholders think about the project and how you report progress to them.

Stories

A story is a slice of the epic that delivers value to a user on its own: "As a customer, I can upgrade my plan so that I get more storage". It should be small enough to finish in a sprint and testable on its own. See how to write user stories for the format.

Tasks

Tasks are the steps developers take to finish a story: add the database column, build the endpoint, update the settings screen, write the tests. They are for the team, not the client, and they rarely deliver value alone.

How big should each level be?

A rough guide that works for most software teams:

• Epic: several sprints, five to twenty stories. Bigger than that and it is really a project or a theme.
• Story: one to a few days of work. If it will not fit in a sprint, split it.
• Task: hours, up to about a day.

The test for a good split is simple: could you demo the story to a client and have them understand what changed? If not, it is probably a task wearing a story's clothes.

Running sprints right now? See how Flow handles boards, sprints and burndown together. Get started with Flow →

Splitting epics into stories

Slicing is a skill. Some patterns that work:

1. By workflow step. Browse plans, choose a plan, pay, confirm.
2. By user type. Admins first, then regular users.
3. By business rule. Monthly billing first, annual billing next.
4. Happy path first. Build the success case, then handle errors and edge cases in follow-up stories.

Avoid slicing by technical layer ("backend story", "frontend story"). Neither half delivers anything a user can see.

If you start from a big, fuzzy project, a work breakdown structure helps you find the epics before you write a single story.

Jira's hierarchy and the alternatives

Jira popularised the epic, story and sub-task hierarchy for software teams, and its flexibility means you can add extra levels if your organisation needs them. Teams looking for a Jira alternative usually keep the same mental model, because it works, and look for less configuration to get there.

How Flow helps

• Planner timeline with epics, milestones and stories. See each epic's stories laid out over time, with milestones marking the dates that matter to clients.
• Sub-tasks under stories. Developers break stories into sub-tasks without cluttering the board.
• Linked tickets and merged duplicates. Link related stories across epics, and merge duplicates with their history preserved.
• Turn a diagram into tickets. Sketch an epic's flow on a diagram board and Livex Flow's AI proposes the stories, developer tickets or sub-tasks for you to review.