How to Write an Epic: A Guide for Product Managers
An epic in product management is a body of work that sits between high-level strategic themes and the individual user stories that make up sprint backlogs. It’s a unit of planning that’s large enough to carry strategic meaning — telling the story of a major capability or workflow improvement — while being specific enough to be executed across a set of defined development sprints.
Understanding what epics are, when to write them, and how to write them well is one of the most practical planning skills in a product manager’s toolkit.
Where Epics Fit in the Planning Hierarchy
The agile planning hierarchy flows from broad to specific:
Strategic themes: The major areas of product investment (e.g., “Improve enterprise security and compliance”)
Epics: The specific large-scale capabilities or workflow improvements within a theme (e.g., “Implement single sign-on (SSO) for enterprise customers”)
User stories: The individual feature interactions that together make up the epic (e.g., “As an enterprise admin, I want to configure SSO via SAML so that my team can access the product using our corporate identity provider”)
Tasks: The specific development work items within each story
Epics provide the organizing unit that makes large-scale product work plannable and trackable over multiple sprints without losing the strategic context that makes each story meaningful.
What Makes a Good Epic
It has a clear narrative: A well-written epic can be summarized in a sentence or two that explains the capability being built, for whom, and why it matters. If the epic doesn’t have a clear narrative — if it’s essentially just a label on a collection of related stories — it’s not providing the planning value that epics are designed to provide.
It’s sized for execution: An epic should be completable in a meaningful unit of time — typically between one and three months of development work. Epics that are too large aren’t really epics; they’re programs or initiatives that need to be broken down further. Epics that are too small are essentially just user stories with extra steps.
It has clear acceptance criteria at the epic level: What does it mean for the epic to be “done”? What capability will exist when the epic is complete that doesn’t exist today? Having epic-level acceptance criteria prevents the drift that occurs when individual stories are completed but the intended capability is never quite fully realized.
It connects to a strategic theme: Every epic should be traceable to a strategic theme, and the connection should be obvious. If an epic’s connection to the product strategy requires significant explanation, it may be a feature without strategic grounding that deserves more scrutiny before being committed to.
The Epic Description Format
A useful epic description structure:
- Overview: One or two sentences explaining the capability and its strategic significance
- User context: Who benefits from this capability and how they currently address the need without it
- Scope: The high-level scope of what the epic includes and explicitly excludes
- Success criteria: How the team will know the epic has achieved its purpose
- Dependencies: What other work this epic depends on or creates dependencies for
Key Takeaways
Epics are the planning unit that makes large-scale product development coherent — providing the narrative bridge between strategic intent and daily development work. Well-written epics have a clear purpose, appropriate scale, explicit acceptance criteria, and visible connection to the product strategy. Building the discipline of writing epics well is one of the most impactful investments in planning quality a product team can make.