short link: http://goo.gl/g2rG1n
Also Known As:
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.