Pattern of the Month: Epic
Learn more about how an epic is used as an organizing tool within Agile roadmapping in this article.
Join the DZone community and get the full member experience.Join For Free
The practice of capturing backlog items as user stories is well-established, to the point that many now consider them indispensable to an Agile way-of-working. In short, a user story is a placeholder for a conversation about a possible requirement. It isn’t so much a requirement specification as a vehicle through which a team can evolve a shared cognizance of scope. A user story can, therefore, be seen as a very practical construct. It allows for an emergent understanding of what the requirements actually are.
An Agile sub-culture has developed around these “stories” and the practices through which they are best managed. For example, user story mapping is a popular technique which has emerged as a discipline in its own right, and there are training courses on how to apply it. Other techniques present lower barriers to entry and usage and are effectively considered part and parcel of the user story lexicon. The most widely adopted of these is arguably the Epic.
In 2004, Mike Cohn introduced the idea of an “epic” in his book User Stories Applied. He defined an epic as a big user story, one that is too large to be developed and delivered in a single iteration, and which may, therefore, require breaking down into smaller actionable stories.
This definition of an epic, although canonical, has lead to inconsistencies in how they are abstracted and managed. The INVEST criteria — which are commonly used to qualify a well-formed user story — are strained when applied to an epic. "INVEST" means that a story ought to be independent of others, negotiable in the method of its implementation, valuable to stakeholders, estimated, small enough to be actioned within an Agile timescale, and testable. By definition, however, an epic will not be “small” enough to be resolved within a single Sprint. To head off the threat of acrostic discord, some weaken the "S" in INVEST to indicate “sized” rather than “small.”
The popular technique of writing a user story card in the form As a <role> I need <capability> so that < benefit> is quite applicable to epics. The basic user story format of Card, Conversation, and Confirmation also remains valid, and can promote the development of epics in the first place. Since user stories are emergent, we may expect them to decompose through refinement, a process often referred to as "story splitting." Many have experienced how today’s story has a tendency to become tomorrow’s epic, once it becomes clear how much work it encompasses.
Even after splitting, an epic does not necessarily fade into irrelevance. It can still be a useful abstraction and organizing principle for product backlog management, since it may correlate to a significant and expected business outcome. A hierarchy can then be established within which specific stories make valuable contributions to an epic result.
Themes are another organizing principle related to epics, and are often confused with them. This term might sometimes be used to describe a wider grouping of epics, or as a cross-cutting concern that encompasses multiple stories. In this latter usage, the stories in a theme might belong to different epics or to no epic at all. Hence, a theme can impact backlog ordering without necessarily implying hierarchical decomposition. For example, stories might be grouped into a certain “theme” that a given Sprint could address, such as user account management or inventory control, and thus give shape to a potential Sprint Goal.
A theme can be considered as a kind of epic in so far as it represents a grouping construct for user stories. However epics and themes are defined, simplicity in this matter ought to be held as a virtue. It’s important that teams don't over-complicate matters with elaborate tracking and correlation mechanisms. These can bring significant and wasteful overheads via increased dependency management.
Epic is Pattern of the Month at Agilepatterns.org
Intent: Allow certain items on a backlog to be jointly or provisionally represented in a grouped way
- "Enough is as good as a feast."
- "Half a loaf is better than no bread at all."
Also Known As:
- Theme (although this is more commonly used to describe a grouping of epics)
Motivation: Requirements may represent business value without being detailed or focused enough to be actionable User Stories. A way is needed to capture this scope so that actionable stories can be represented, even though they may not yet have been written.
Structure: A project backlog will consist of multiple backlog items, some of which may be nested. An item that may potentially nest one or more other items that are related by some common purpose is termed an Epic. An Epic will be complete when all of its member items conform to the terms of the Definition of Done. All backlog items, including Epics, must have a size.
Applicability: Epics are applicable whenever a grouping construct is needed for Product Backlog Items (PBI’s). They may also be used as a placeholder for items that have not yet been identified, but for which an over-arching business purpose is clear.
Consequences: Epics can be difficult to size since important details may be absent. They represent scope that may be associated with significant risk. They must generally be broken down further before a team can accept the relevant work into a Sprint Backlog.
Implementation: Epics are widely used to represent User Stories at a high level in a Product Backlog. DSDM, Scrum, and XP commonly use epics as a placeholder grouping construct for undefined project requirements. Epics are less commonly associated with Lean-Kanban, at least in a Business As Usual context, since they do not align to the small and repeatable changes that typify such workstreams.
- User Stories, Epics and Themes, by Mike Cohn
- Epics and Ready Stories, by Roman Pichler
- User Stories - Epics and Themes, by Charles Bradley
Opinions expressed by DZone contributors are their own.