Epic

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.

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.

Intent: Allow certain items on a backlog to be jointly or provisionally represented in a grouped way

Proverbs:

    • 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.

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.

See Also: