Agile guide · Agile practices
Agile Epics: What They Are, How to Write Them, With Examples
An epic is a large piece of work that is too big to finish in one iteration, so it is broken down into smaller user stories. Epics group related stories under a single goal, which helps teams plan releases and track progress on bigger outcomes.
Key takeaways
- An epic is a large backlog item that is broken down into user stories sharing one goal.
- Write epics around outcomes, with a success measure and clear boundaries.
- Split epics into thin, valuable slices rather than technical layers.
- Close epics when their goal is met; ongoing areas of work are themes.
What an epic is
Epics sit above user stories in the backlog hierarchy. A user story should be small enough to finish within a sprint; an epic usually takes several sprints and may involve more than one team. An epic describes an outcome ("members can book and pay for classes online"), and its stories describe the individual slices that deliver it.
- Theme: a broad area of focus that spans several epics, such as "improve member self-service".
- Epic: a large body of work with a clear goal, such as "online class booking".
- Feature: a term used by some teams and frameworks, such as SAFe, for a mid-sized piece of functionality. In SAFe, epics sit above features.
- User story: a small, valuable slice that fits in one sprint.
- Task: a technical step needed to complete a story.
How to write an epic
- Name it by outcome: a short title that describes the result, not the technical work.
- Write a one-line goal: who benefits and why. A story-style sentence works: "As a member, I want to book classes online so that I don't have to phone the gym."
- Define success: one to three measures, such as "60% of bookings made online within three months".
- Set boundaries: list what is in and out of scope.
- Add acceptance criteria at epic level: the conditions that must be true for the epic to be considered done.
- Note dependencies and risks: other teams, systems or decisions it relies on.
- Split into stories: break it into stories the team can deliver in a sprint, starting with a thin end-to-end slice.
Ways to split an epic into stories
| Splitting pattern | Example for "online class booking" |
|---|---|
| By workflow step | View timetable; book a class; cancel a booking |
| By user type | Members book; staff manage capacity; instructors see attendance |
| By business rule | Book a free class; book a paid class; book with a membership credit |
| Simple first, then complex | Book one class; then recurring bookings |
| By data or channel | Book on the web; then in the mobile app |
| Happy path, then exceptions | Successful booking; then full class and waiting list |
Worked example
Epic: Online class booking. Goal: let members book and cancel classes without phoning. Measure: phone bookings fall from about 400 to under 150 a week within three months.
- Story 1: As a member, I want to see this week's timetable so that I can choose a class (3 points).
- Story 2: As a member, I want to book a place in a class so that it is reserved for me (5 points).
- Story 3: As a member, I want to cancel a booking so that someone else can take my place (3 points).
- Story 4: As a member, I want to join a waiting list when a class is full (5 points).
- Story 5: As a member, I want a reminder the day before my class (2 points).
The epic totals 18 points. With a velocity of about 12 points per sprint, the team can expect to finish it in around two sprints, alongside other work. Track progress with an epic burndown that shows remaining points over time.
Common mistakes
- Epics that never end: keep each epic tied to a goal so it can be closed; ongoing work belongs in a theme.
- Splitting by technical layer: "database", "API" and "UI" stories deliver nothing usable on their own.
- Writing every story up front: split the near-term part in detail and leave later parts rough.
- Too many open epics: working on many at once spreads the team thin and delays every outcome.
- Confusing epics with projects: an epic is a backlog item, not a separate plan with its own team and budget.
Free templates for this topic
Frequently asked questions
What is an epic in Agile?
A large body of work that is too big for one iteration and is broken down into smaller user stories that share a goal.
How big should an epic be?
Large enough to need several sprints, but small enough to finish within a release or a few months. If it never ends, it is probably a theme.
Who writes epics?
Usually the product owner or product manager, with input from the team and stakeholders.
Is an epic part of Scrum?
No. The Scrum Guide does not mention epics. They are a common practice for organising the product backlog.
What is the difference between an epic and a user story?
An epic is a large goal spanning several sprints; a user story is a small slice that fits in one sprint. See epics vs stories vs tasks.
What is the difference between an epic and a theme?
A theme is a broad area of focus that can contain several epics; an epic is a specific body of work with a finish line.
What is the difference between an epic and a feature?
It depends on the framework. In SAFe, epics are larger and contain features; some teams use the words interchangeably.
Do epics have story points?
Teams often give epics a rough size, or sum the points of their stories, to forecast how many sprints they will take.
Can an epic span multiple teams?
Yes. Larger epics are often shared, with each team owning a set of stories.
How do you track progress on an epic?
With an epic burndown or a progress bar showing completed versus remaining stories or points; most project management tools offer this.
Should an epic have acceptance criteria?
It helps. High-level acceptance criteria define when the epic as a whole is done.