Epic
In short
An epic is a large body of work in Agile that is too big to finish in one sprint, so the team breaks it down into smaller user stories delivered over time.
What is an epic in Agile?
An epic is a large piece of work that is too big to complete in a single sprint, so it is broken down into smaller user stories. It describes a significant capability or outcome, such as letting customers pay with a saved card or supporting multiple languages, and it may take several sprints or even several teams to finish. Epics are not an official Scrum term, but they are widely used with Scrum, Kanban, and scaled Agile frameworks.
An epic usually starts as a rough item in the product backlog with a short statement of its goal and the value it should deliver. As it rises in priority, the team splits it into stories that each deliver a thin slice of working value, for example by workflow step, by type of user, or by data variation, and each story gets its own acceptance criteria. Tracking tools link stories to their epic so progress can be followed, and an epic is complete when its goal is met, which may happen before every original story is built.
If an epic is a book, its user stories are the chapters: you can't write the whole book in one sitting, but you can finish it one chapter at a time. Many organizations use a hierarchy of work items, with themes or initiatives at the top, then epics, then stories, then tasks, although the exact names vary between teams and tools.
Epics are often confused with user stories, but the difference is size, not format. Both can be written as As a user, I want something, so that I get some benefit, yet a story should fit in one sprint while an epic cannot. Some frameworks also add a feature level between epics and stories, so the same piece of work might be called an epic in one company and a feature in another.
Key takeaways
- An epic is work too large to finish in one sprint.
- Epics are split into user stories that each deliver a slice of value.
- The difference between an epic and a story is size, not format.
- An epic is done when its goal is met, not necessarily when every story is built.
- Epics are a common convention, not an official Scrum artifact.
Example
Epic: Customers can pay with a saved card
Goal: Cut checkout time for returning customers
User stories:
1. As a customer, I want to save my card after a purchase, so I don't retype it.
2. As a customer, I want to pay with a saved card in one click.
3. As a customer, I want to delete a saved card from my account.
4. As a customer, I want a warning before a saved card expires.
Progress: 2 of 4 stories doneReaders ask
What is the difference between an epic and a user story?
A user story is small enough to finish within one sprint, while an epic is too big and must be split into several stories. Both describe value for a user; the difference is size.
How long should an epic take?
There is no fixed rule, but most epics take a few sprints to a few months. If an epic drags on much longer, it is often a sign that it should be split into smaller epics with clearer goals.
See also
- User StoryTeams & Process, p. 30A user story is a short, plain-language description of a feature told from the user's point of view, explaining who wants it, what they want, and why.
- Product BacklogTeams & Process, p. 17The product backlog is a single ordered list of everything a team might do to improve a product, such as features, fixes, and technical work.
- Story PointsTeams & Process, p. 28Story points are a unit Agile teams use to estimate the relative size of work items, combining complexity, amount of work, and uncertainty rather than hours.
- SprintTeams & Process, p. 26A sprint is a fixed-length period of one month or less, often two weeks, in which a Scrum team works toward one goal and produces a usable product increment.
- Acceptance CriteriaTeams & Process, p. 1Acceptance criteria are the specific, testable conditions a single user story or backlog item must meet before the Product Owner accepts it as complete.
- AgileTeams & Process, p. 2Agile is an approach to software development that delivers working software in small, frequent increments and adjusts plans based on regular feedback.
Spotted a mistake or something missing on this page?Suggest an edit