What Is an Epic in Agile? Definition, Structure & How to Write One
An epic is a large body of work in agile product development that represents a significant feature, capability, or initiative — one that is too large to be completed in a single sprint and must therefore be broken down into smaller user stories that can be delivered incrementally over multiple iterations.
Epics sit in the middle of the agile work hierarchy: larger than individual user stories (which represent specific, completable units of user value), but smaller than strategic themes (which represent broad, high-level product goals).
The Agile Work Hierarchy
To understand where epics fit, it helps to see the full hierarchy:
| Level | Description | Example |
|---|---|---|
| Theme | Strategic goal or area of focus | “Improve new user onboarding” |
| Epic | Large body of work serving the theme | “Build guided setup wizard” |
| User Story | Specific, implementable unit of value | “As a new user, I can connect my calendar so that I see my existing events” |
| Task | Technical subtask within a story | “Design calendar permissions UI” |
Epics are the bridge between high-level strategy and day-to-day development. They define what the team is building across multiple sprints; user stories define the specific pieces.
What Makes Something an Epic
An item typically qualifies as an epic when it:
- Cannot be realistically completed in a single sprint
- Contains multiple distinct user-facing outcomes that can be delivered independently
- Represents a coherent body of work toward a specific user goal or product capability
- Requires coordination across multiple development cycles
How to Write an Epic
Epics are typically written with enough context to guide story development, but not so much detail that they constrain solution design. A well-structured epic includes:
Epic Title
A clear, descriptive title that names the capability or outcome. “Self-service account setup” is better than “Setup improvements.”
Goal and Context
Why this epic exists: the user need being addressed, the business objective it serves, and the context that makes it a priority now.
Acceptance Criteria (High-Level)
The high-level conditions that define what “done” looks like for the epic as a whole. These are not the detailed acceptance criteria of individual stories — they’re the broader markers that indicate the epic has achieved its purpose.
Assumptions and Constraints
Known limitations, dependencies, or assumptions that will shape how stories within the epic are designed and developed.
Child Stories
The list of user stories that make up the epic, typically in rough priority order. These are often developed iteratively — not all stories are fully defined before the epic begins, particularly for longer-horizon work.
Epic Planning and Management
Breaking Epics into Stories
The process of decomposing an epic into user stories should be collaborative — involving product managers, engineers, and designers. Good story decomposition creates stories that are independently valuable and testable, not just technical task breakdowns.
Epic-Level Estimation
Epics are sometimes estimated in relative terms (story points, t-shirt sizes, or number of sprints) at a high level, before stories are fully defined. These estimates are deliberately rough — they inform capacity planning and roadmap timelines, not sprint-level commitments.
Managing Epics Across Sprints
Because epics span multiple sprints, they require ongoing management: tracking story progress, adjusting scope as learnings emerge, and communicating status to stakeholders at the epic level rather than the story level. Most project management tools (Jira, Linear, Shortcut) support epic-level views for this reason.
Epics on the Product Roadmap
Epics are often the appropriate level of granularity for product roadmaps. Roadmaps organized around epics are specific enough to be meaningful — stakeholders understand what’s being built — without being so granular that every user story appears. This makes the roadmap a useful communication tool for stakeholders who need direction without implementation detail.
Key Takeaways
Epics are the essential middle layer of agile product planning. They translate strategic themes into concrete, manageable bodies of work that teams can plan, estimate, and deliver over time. Well-written epics create the structure that keeps long-horizon product work organized, visible, and aligned with the strategy it’s meant to serve.