Agile Glossary

Epic

What is Epic?

An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.

There is no standard form to represent epics. Some teams use the familiar user story formats (As A, I want, So That or In Order To, As A, I want) while other teams represent the epics with a short phrase.


Expected Benefits

Epics allow you to keep track of large, loosely defined ideas in your backlog without the need to overpopulate your backlog with multiple items. You can remember a vague idea with one backlog item until your team identifies the need to deliver the outcome that the epic enables. At that point, your team can split the epic into smaller user stories during backlog refinement.

Epics allow you a way to establish a hierarchy for your backlog items where the Epic represents the original idea often closely related to a particular outcome. The user stories associated with that epic represent the various aspects of the solution you need to deliver or the options you have for satisfying that need.

You may also see the concept of themes used for grouping user stories dealing with the same topic. The theme concept is frequently used to group user stories that were identified separately together and can be used as a decision filter of sorts to decide what stories to group into a particular sprint or delivery. Themes are typically not used as a level in a backlog hierarchy.


Common Pitfalls

Teams can overcomplicate their use of epics by viewing them as more than just large user stories. This is apparent when the team creates complex mechanisms to differentiate between epics and user stories (and potentially other backlog hierarchies) as well as creates extensive tools for tracking epics separately from other backlog items.

Both of these actions result in wasted effort in the form of whether something is an epic or a user story and time spent tracking information about a backlog item that is intended to be a placeholder for future discussions that will result in more finely-grained backlog items.

Teams may also try to estimate epics even though these items typically are very vague in nature and prone to a great deal of uncertainty, reducing the likelihood of reliable or useful estimates.


When Applicable

The concept of epics is particularly useful when you are following a framework such as Scrum that has explicit timeboxed iterations (ie sprints). Since you organize your work into 2 – 4 week sprints, you may find a placeholder that represents work that cannot be finished within that time frame helpful.

Epics are also useful when there is value in having a simple hierarchy in your product backlog.


Origins

2004: Mike Cohn introduced the concept of an epic as a large user story in his book User Stories Applied For Agile Software Development.


Further Reading

User Stories Applied For Agile Software Development by Mike Cohn

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now