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
