Epic
An epic is a large body of work that can be broken down into smaller, more manageable pieces called user stories or tasks. Epics represent significant product initiatives-features, capabilities, or improvements that are too big to complete in a single sprint but coherent enough to be tracked as a unified effort. They provide a middle layer of organization between high-level strategic themes and the granular work items teams execute day to day.
Why it matters
Without epics, product backlogs tend toward two extremes: either overwhelming lists of hundreds of tiny stories without clear organization, or vague strategic initiatives without actionable detail. Epics bridge this gap by grouping related work into meaningful chunks that can be planned, tracked, and communicated.
Epics make roadmap communication possible. Stakeholders rarely care about individual user stories-they want to know when major capabilities will be available. Epics provide the right level of abstraction for roadmap conversations while remaining grounded in specific, estimable work.
For teams, epics create focus. Working on disparate stories scattered across many initiatives fragments attention; working on stories that all contribute to the same epic creates coherent progress toward a meaningful goal.
Characteristics of good epics
Size and scope
Epics should be large enough to represent meaningful value but small enough to be completed in a reasonable timeframe. Common guidelines suggest epics should be completable in one to three months of team effort, though this varies significantly based on team size and product complexity.
An epic that takes six months or longer often indicates something that should be broken into multiple epics. An epic that takes less than a sprint is probably just a large user story.
Clear outcome
Good epics describe outcomes, not just activities. "Build a mobile app" is an activity; "Enable customers to manage their accounts from mobile devices" is an outcome. Outcome-focused epics help teams make better decisions about implementation while keeping sight of why the work matters.
Testable completion
There should be clear criteria for when an epic is done. This might be a specific capability delivered, a metric achieved, or a defined set of user stories completed. Without clear completion criteria, epics drag on indefinitely, accumulating scope and never quite finishing.
Independent value
Ideally, completing an epic delivers value even if other epics aren't finished. This isn't always achievable-some epics depend on foundational work from others-but maximizing independence enables more flexible prioritization and earlier value delivery.
Epic structure
Hierarchy
Epics fit within a typical agile hierarchy:
Themes or initiatives represent the highest level of strategic organization-major product directions or company goals. A theme might be "improve customer retention" or "expand into enterprise market."
Epics are large bodies of work that contribute to themes. Under "improve customer retention," you might have epics for "onboarding improvements," "engagement notifications," and "loyalty program."
User stories are individual pieces of functionality within epics. The "onboarding improvements" epic might contain stories for "welcome email sequence," "guided product tour," and "progress indicators."
Tasks are implementation-level work items that engineers break stories into for day-to-day execution.
Epic content
A well-documented epic typically includes:
The level of documentation varies by organization and epic complexity. Some teams maintain detailed epic specifications; others keep minimal documentation and rely on conversation.
Working with epics
Creating epics
Epics typically emerge from strategic planning processes-roadmap discussions, customer feedback analysis, or business initiative planning. The product owner or product manager usually creates and maintains epics, though input from engineering, design, and stakeholders shapes their definition.
When creating an epic, start with the outcome and work backward. What capability does this enable? What problem does it solve? Only after the outcome is clear should you think about the stories and tasks required to achieve it.
Breaking down epics
Decomposing epics into user stories is an ongoing process. You don't need every story defined before starting an epic-in fact, premature decomposition often produces stories that need to be rewritten as understanding develops.
A useful pattern is progressive elaboration: break down stories for the near term in detail while keeping future work at higher levels of abstraction. As work progresses and learning accumulates, elaborate the next set of stories.
Several techniques help with decomposition:
Workflow steps break down by stages of a process. An e-commerce checkout epic might decompose into cart review, shipping selection, payment processing, and confirmation.
User variations break down by different user types or scenarios. A reporting epic might decompose into basic reports for all users, advanced reports for analysts, and scheduled reports for managers.
Data variations break down by different data types or sources. An import epic might decompose into CSV import, API integration, and manual entry.
Operations break down by CRUD operations. A content management epic might decompose into create, edit, publish, and archive capabilities.
Tracking progress
Epic progress can be measured in several ways:
Story completion counts how many stories are done versus total. Simple but can be misleading if story sizes vary.
Story points sums completed points versus total estimated points. More accurate than story count but requires consistent estimation.
Percentage complete asks the team to estimate overall progress. Subjective but can capture factors that story counts miss.
Outcome metrics track progress toward the epic's intended outcome. If the epic aims to reduce support tickets, track that metric directly.
Most teams use a combination, with story-based metrics for operational tracking and outcome metrics for validating actual value delivery.
Common challenges
Epics that never end
Some epics accumulate scope indefinitely, becoming permanent homes for loosely related work. This defeats the purpose of epics by removing the sense of progress and completion.
The solution is stricter scope definition and willingness to close epics when their original objectives are met. New related work can spawn new epics rather than extending existing ones.
Too many epics
Backlogs with dozens of active epics provide little organizational benefit-the portfolio is as overwhelming as a flat story list. Limit work in progress at the epic level, keeping only a handful of epics active while others wait in a prioritized queue.
Epic vs. feature confusion
Terminology varies across organizations. Some use "epic" and "feature" interchangeably; others distinguish them (features as what users see, epics as bodies of work that may or may not be user-visible). The labels matter less than consistent usage within your organization.
Premature decomposition
Breaking an epic into detailed stories too early often wastes effort when those stories need to change based on learning. Decompose just in time, keeping future work at higher levels of abstraction.
Epics and roadmaps
Epics provide the natural unit for roadmap communication. A roadmap showing "Q2: Onboarding improvements, Q3: Mobile app, Q4: Enterprise features" communicates meaningful information at an appropriate level of abstraction. Stakeholders understand what's coming without drowning in implementation details.
This requires epics that are sized appropriately for roadmap timeframes. If epics routinely take two quarters to complete, they may be too large; if they finish in weeks, they may be too small for roadmap-level visibility.
Klero helps product teams manage epics effectively by connecting customer feedback to epic prioritization. When deciding which epics to pursue next, teams can see which capabilities customers are actually requesting, how feedback volume varies across potential initiatives, and how shipped epics affect customer satisfaction.
