Quick Overview: Epic vs Story
The short answer: An epic is a large body of work that captures a broad product initiative, while a user story is a small, specific piece of functionality that delivers value to a user. Epics are broken down into multiple user stories that can each be completed within a single sprint.
Think of it this way: if you were building a house, the epic would be "Build the kitchen" and the individual stories would be "Install the countertops," "Connect the plumbing for the sink," and "Wire the electrical outlets." Each story is a concrete, deliverable piece of work that contributes to the larger epic.
This distinction matters because it directly impacts how teams plan, estimate, and deliver work. Epics help product managers and stakeholders think strategically about what the product needs to accomplish over weeks or months. Stories help development teams focus on what they can build and ship within a two-week sprint. Without a clear understanding of both, teams either lose sight of the big picture or fail to break work into actionable chunks.
In practice, the relationship between epics and stories is one of the most fundamental concepts in Agile product management. Getting it right enables better sprint planning, clearer communication with stakeholders, and more predictable delivery. Getting it wrong leads to bloated backlogs, stories that never seem to get done, and teams that struggle to demonstrate meaningful progress.
Epic
- Large body of work spanning multiple sprints
- Provides strategic context and business goals
- Broken into smaller, deliverable stories
- Tracked for overall initiative progress
- Owned primarily by the product manager
User Story
- Small unit of work completable in one sprint
- Focuses on specific user needs and actions
- Contains detailed acceptance criteria
- Estimated and planned at the sprint level
- Co-created by PM and development team
Side-by-Side Comparison Table
The table below provides a comprehensive comparison of epics and user stories across every important dimension. Use this as a quick reference when you need to decide whether a backlog item should be structured as an epic or a story.
| Aspect | Epic | User Story |
|---|---|---|
| Definition | A large body of work that can be broken down into smaller pieces | A small, specific unit of work that delivers value to a user |
| Size / Scope | Large — spans multiple sprints and potentially multiple teams | Small — completable within a single sprint by one team |
| Time to Complete | Weeks to months (typically 1-6 months) | Hours to days (fits within one sprint) |
| Level of Detail | High-level description with strategic context and goals | Detailed requirements with specific acceptance criteria |
| Written By | Product manager or product owner, with leadership input | Product manager, often co-created with development team |
| Sprint Fit | Does not fit in a single sprint — too large | Must fit within a single sprint to be sprint-ready |
| Acceptance Criteria | Broad success metrics and completion conditions | Specific, testable conditions that must be met |
| Dependencies | May have cross-team and cross-system dependencies | Should be as independent as possible (INVEST criteria) |
| Estimation | Rough order of magnitude (weeks or sprints) | Story points, T-shirt sizes, or ideal hours |
| Examples | "Implement user onboarding flow" or "Build reporting dashboard" | "As a user, I want to reset my password via email" |
| Hierarchy Level | Sits above stories, below themes or initiatives | Sits below epics, above tasks and subtasks |
What Is an Epic?
An epic is a large body of work in Agile that represents a significant product initiative or feature area. It is too big to be completed in a single sprint, so it must be decomposed into smaller user stories that teams can deliver incrementally. Epics serve as containers that group related work together, providing strategic context for why the work matters and how it connects to broader product goals.
The term "epic" comes from the literary concept of an epic narrative: a grand, sweeping story that contains many smaller stories within it. In Agile, epics work the same way. They describe a complete user experience or product capability at a high level, and the individual stories within the epic provide the granular detail needed for implementation.
Key Characteristics of Epics
- 1.Too large for a single sprint. If a piece of work can be completed within one sprint, it is a story, not an epic. Epics by definition span multiple sprints and represent sustained effort over weeks or months.
- 2.Decomposable into stories. Every epic should be breakable into at least three to five user stories. If it cannot be meaningfully decomposed, it may actually be a story that just needs clearer acceptance criteria.
- 3.Tied to business objectives. Epics should connect to product strategy, OKRs, or business goals. They answer the question "Why are we doing this?" at a strategic level.
- 4.Progressively elaborated. Epics start vague and become more detailed over time. Early on, you might only know the general goal. As the team works through the epic, stories are defined, refined, and adjusted based on what they learn.
- 5.Tracked at the portfolio or roadmap level. Stakeholders and leadership typically track progress at the epic level rather than individual story level because epics represent meaningful product milestones.
Real-World Epic Examples
Example 1: User Onboarding Redesign
Context: An e-commerce platform has high drop-off during registration. The product team decides to redesign the onboarding flow to improve activation rates.
Epic statement: "Redesign the user onboarding experience to reduce registration drop-off by 30% and increase 7-day activation rate from 25% to 40%."
Child stories might include: Implement social login options, create progressive profiling wizard, add welcome email sequence, build interactive product tour, A/B test simplified registration form.
Example 2: Reporting Dashboard
Context: A B2B SaaS product receives frequent requests from customers who need better visibility into their usage data and ROI metrics.
Epic statement: "Build an analytics dashboard that allows customers to track key usage metrics, generate custom reports, and export data for stakeholder presentations."
Child stories might include: Display daily active users chart, implement date range selector, create CSV export functionality, build custom report builder, add scheduled report emails, design dashboard widget library.
Example 3: Mobile Payment Integration
Context: A food delivery app wants to support Apple Pay, Google Pay, and saved card payments to reduce checkout friction and increase order conversion.
Epic statement: "Integrate mobile payment methods (Apple Pay, Google Pay, saved cards) to reduce checkout time by 50% and increase order completion rate by 15%."
Child stories might include: Implement Apple Pay SDK integration, add Google Pay support on Android, build saved card management screen, create one-tap reorder with saved payment, implement PCI-compliant card tokenization, add payment method selection UI.
When to Create an Epic
Create an epic when you have a product initiative that requires multiple stories across multiple sprints. Typical triggers include: a new feature that requires design, frontend, backend, and QA work; a strategic initiative from your product roadmap; a customer-facing improvement that involves multiple touchpoints; or a technical migration that will take several iterations to complete. If the work can be captured in a single story with clear acceptance criteria, keep it as a story. Resist the urge to create epics for the sake of organizational neatness when a story will suffice.
What Is a User Story?
A user story is a short, simple description of a piece of functionality told from the perspective of the person who desires the new capability—usually a user or customer of the system. User stories are the fundamental building blocks of the Agile product backlog and represent the smallest unit of work that delivers value.
Unlike traditional software requirements documents that focus on technical specifications, user stories emphasize the human element: who needs the functionality, what they need to accomplish, and why it matters to them. This user-centered approach ensures that development teams build solutions that actually solve real problems rather than just implementing features for their own sake.
The User Story Format
"As a [type of user], I want [action or feature], so that [benefit or value]."
As a... identifies who the story is for. This should be a specific user persona or role, not a generic "user." For example: "As a hiring manager," "As a first-time buyer," or "As an admin."
I want... describes the action or capability they need. Be specific about what they want to do, not how the system should implement it. For example: "I want to filter candidates by experience level" rather than "I want a dropdown menu with experience filters."
So that... explains the value or benefit. This is the most commonly omitted part, but it is arguably the most important. It answers "why?" and helps the team make better implementation decisions. For example: "so that I can quickly find qualified applicants without reading every resume."
The INVEST Criteria
Well-written user stories follow the INVEST criteria, an acronym coined by Bill Wake that describes six qualities of a good user story:
Independent
Stories should be self-contained and not depend on other stories. This allows teams to prioritize and deliver them in any order.
Negotiable
Stories are not rigid contracts. The details should be open to discussion between the product owner and the development team.
Valuable
Every story must deliver value to the end user or the business. If a story has no clear value, it should be questioned or removed.
Estimable
The team should be able to estimate the effort required. If a story is too vague to estimate, it needs further refinement.
Small
Stories should be small enough to complete within a single sprint. If it takes longer, break it down further.
Testable
There must be clear criteria to determine when the story is done. If you cannot test it, you cannot verify it is complete.
Acceptance Criteria Examples
Acceptance criteria define the specific conditions that must be met for a story to be considered complete. They remove ambiguity and give developers and QA engineers clear targets to work toward. Here are examples for the story "As a user, I want to reset my password via email, so that I can regain access to my account."
Acceptance Criteria:
- Given a registered user on the login page, when they click "Forgot Password," they see a form to enter their email address.
- Given a valid email address is submitted, a password reset link is sent within 60 seconds.
- The reset link expires after 24 hours and displays an appropriate message if used after expiry.
- The new password must meet the existing password policy (8+ characters, one uppercase, one number).
- After successful password reset, the user is automatically logged in and redirected to their dashboard.
- If an unregistered email is entered, the system displays a generic "If an account exists, a reset email has been sent" message for security.
The Agile Hierarchy Explained
Epics and stories do not exist in isolation. They are part of a broader hierarchy that helps organizations structure work from high-level strategy down to individual tasks. Understanding this hierarchy is essential for keeping your backlog organized and ensuring that every piece of work connects to a meaningful business objective.
Theme / Initiative
The highest level of the hierarchy. Themes represent broad strategic areas or company objectives that guide all product work. Examples: "Improve Customer Retention," "Expand to Enterprise Market," or "Reduce Operational Costs." Themes typically align with annual goals or OKRs and may span an entire year.
Epic
Large bodies of work that contribute to a theme. Each theme typically contains 3-8 epics. Epics are the primary unit of work on product roadmaps and represent features or initiatives that take weeks to months. Examples: "Build Customer Health Score Dashboard," "Implement Enterprise SSO," or "Automate Invoice Processing."
User Story
Specific, deliverable pieces of work that belong to an epic. Each epic typically contains 5-15 stories. Stories are the unit of work for sprint planning and are sized to be completable within a single sprint. Examples: "As an account manager, I want to see a customer's health score on their profile page," or "As an admin, I want to configure SSO settings from the security panel."
Task / Subtask
The most granular level of work. Tasks are the technical implementation steps required to complete a story. They are typically created by developers during sprint planning and are measured in hours rather than story points. Examples: "Create database migration for health_scores table," "Write API endpoint for GET /customers/:id/health-score," or "Add unit tests for score calculation logic."
This hierarchy provides a clean mapping between strategy and execution. Leadership cares about themes and epics. Product managers work across epics and stories. Developers focus on stories and tasks. Each level provides the right amount of detail for its audience without overwhelming them with information they do not need.
How Epics and Stories Relate
The relationship between epics and stories is not simply hierarchical—it is dynamic and evolves over the course of product development. Understanding this relationship is key to effective Agile planning and delivery.
Breaking Down Epics Into Stories
The process of decomposing an epic into stories is called "story mapping" or "epic decomposition." This is typically done during backlog refinement sessions and follows a progressive approach. You do not need to define all stories upfront. Instead, define the stories for the next one to two sprints in detail, and keep the remaining stories at a higher level. This respects the Agile principle that requirements will change as the team learns more.
A common technique is to identify the "minimum viable" version of the epic first. Ask: "What is the smallest set of stories that would deliver enough value to be worth releasing?" These stories become your first sprint or two of work. Then layer on enhancement stories in subsequent sprints. This approach ensures you deliver value early and often, rather than waiting until the entire epic is complete.
Tracking Progress at the Epic Level
One of the primary benefits of the epic-story relationship is progress visibility. Stakeholders rarely want to hear about individual stories. They want to know: "How far along is the new reporting dashboard?" By tracking the percentage of stories completed within an epic, you can provide clear progress updates. Most project management tools (Jira, Linear, Shortcut) provide epic-level burn-down charts and progress bars that aggregate the status of child stories automatically.
When reporting to stakeholders, frame progress in terms of the epic goal and completed capabilities rather than raw story counts. Saying "We have completed the core data visualization and export features. Next sprint we are tackling the custom report builder, which is the final major piece of the dashboard epic" is far more meaningful than "We have completed 8 of 12 stories."
Handling Scope Changes
As work progresses on an epic, it is common for scope to change. New stories may be discovered, existing stories may be split or combined, and some stories may be deprioritized or removed entirely. This is normal and expected in Agile. The epic provides a stable anchor point even as the individual stories within it evolve. Keep the epic description focused on the desired outcome, and let the stories be flexible in how they achieve it.
How to Write Good Epics and Stories
Writing effective epics and stories is a skill that improves with practice. Here are concrete guidelines with examples for each.
Writing Effective Epics
A good epic should include a clear title, a problem statement, the desired outcome, success metrics, and known constraints. Here is a template:
Epic Title: [Descriptive name for the initiative]
Problem: [What problem are we solving? Who is affected?]
Desired Outcome: [What does success look like?]
Success Metrics: [How will we measure success?]
Scope: [What is in scope and out of scope?]
Dependencies: [What other teams or systems are involved?]
Target Timeline: [When should this be delivered?]
Example: Well-Written Epic
Epic Title: Self-Service Subscription Management
Problem: Customers currently need to contact support to change their subscription plan, add seats, or update billing information. This creates 200+ support tickets per month and frustrates customers who expect self-service capabilities.
Desired Outcome: Customers can independently manage all aspects of their subscription, reducing support tickets related to billing by 80% and improving customer satisfaction scores for account management.
Success Metrics: Reduce billing-related support tickets from 200/month to 40/month. Achieve 90%+ self-service completion rate for plan changes. Improve NPS for account management from 32 to 50+.
Scope: In scope: plan upgrades/downgrades, seat management, billing info updates, invoice history. Out of scope: enterprise contract negotiations, refund processing.
Target Timeline: Q2 2026 (April-June)
Writing Effective User Stories
Vague Story
"As a user, I want to manage my subscription."
Problem: Too broad, no specific action, no value statement, not completable in one sprint. This is actually an epic disguised as a story.
Specific Story
"As a team admin, I want to add new seats to our subscription from the billing settings page, so that I can onboard new team members without contacting support."
Good: Specific user role, clear action, explains the benefit, small enough for one sprint.
Technical Implementation Story
"Refactor the billing module to use Stripe API v3."
Problem: Written from a technical perspective, no user, no value. This is a task, not a story.
User-Centered Story (Even for Technical Work)
"As a customer, I want my subscription changes to take effect immediately, so that I can start using additional features right away without waiting for manual processing."
Good: The technical Stripe upgrade enables this user benefit. The team knows the implementation involves API migration, but the story focuses on user value.
Common Mistakes to Avoid
Even experienced product teams make these mistakes with epics and stories. Being aware of these patterns will help you maintain a healthy, actionable backlog.
1. Writing Stories That Are Actually Epics
The most common mistake is writing a backlog item as a "story" that is far too large to complete in a single sprint. If a story cannot be estimated with reasonable confidence, requires work from multiple teams, or would take more than two weeks of effort, it is probably an epic that needs to be broken down. A good litmus test: can a single developer or pair complete this in a sprint? If not, decompose further.
Fix: If a story feels large, ask "What is the smallest version of this we could ship?" That smallest version is your real story.
2. Creating Epics That Are Too Small
On the opposite end, some teams create "epics" that only contain one or two stories. This adds unnecessary organizational overhead without providing meaningful grouping benefits. If an epic only has two stories, it is likely just a story with subtasks. Reserve the epic level for work that genuinely represents a significant product initiative spanning multiple sprints.
Fix: Before creating an epic, verify it will contain at least 3-5 stories and span at least 2-3 sprints of work.
3. Omitting the "So That" Clause in Stories
Many teams write stories as "As a user, I want X" and stop there. Without the "so that" clause, the development team lacks context about why the feature matters. This leads to poor implementation decisions because developers do not understand the underlying user need. When you know the "why," you can often find better solutions than what was originally proposed.
Fix: Make the "so that" clause mandatory in your story template. If you cannot articulate the benefit, the story may not be worth building.
4. Never Closing Epics
Some teams leave epics open indefinitely, continuously adding new stories to them. This creates "zombie epics" that never reach completion and make it impossible to track real progress. An epic should have a clear definition of done and a finite scope. When the original goals are met, close the epic. If new related work emerges later, create a new epic (for example, "Onboarding V2" or "Dashboard Phase 2").
Fix: Define clear exit criteria for every epic at creation time. Review open epics monthly and close any that have achieved their goals or are no longer relevant.
5. Writing Stories From a Technical Perspective
Stories like "Migrate database to PostgreSQL 16" or "Refactor the authentication module" are technical tasks, not user stories. While technical work is necessary, framing it as a user story helps the team understand the user-facing value of the work and makes it easier to prioritize against feature work. Even infrastructure improvements benefit users indirectly through better performance, reliability, or security.
Fix: Reframe technical tasks in terms of user impact: "As a user, I want the app to load in under 2 seconds, so that I can access my data quickly without frustration."
Tools for Managing Epics and Stories
The right project management tool can make epic and story management significantly easier. Here are the most popular tools used by product teams for backlog management, with their strengths for epic-story workflows.
Jira
The industry standard for Agile teams. Jira provides native support for the full epic-story-task hierarchy with dedicated epic boards, roadmap views, and advanced reporting. Best suited for larger teams that need customizable workflows and integrations with CI/CD pipelines.
Best for: Enterprise teams, scaled Agile, complex workflows
Linear
A modern, fast alternative to Jira with excellent epic (called "Projects") and issue management. Linear is known for its speed, keyboard-first design, and clean interface. It supports cycles (sprints), project tracking, and automatic progress calculations.
Best for: Startups, mid-size teams, developer-focused orgs
Shortcut (formerly Clubhouse)
Strikes a balance between Jira's power and Linear's simplicity. Shortcut uses "Epics" and "Stories" as first-class concepts, with Milestones for higher-level tracking. Its Kanban and iteration views make sprint planning straightforward.
Best for: Small to mid-size product teams
Azure DevOps
Microsoft's integrated development platform provides full work item hierarchy: Epics, Features, User Stories, and Tasks. Tightly integrated with Azure Pipelines for CI/CD, making it ideal for teams in the Microsoft ecosystem.
Best for: Microsoft-stack teams, enterprise environments
Notion
While not a dedicated project management tool, Notion's database relations and views allow flexible epic-story management. Teams can create custom properties, views, and templates. Great for teams that want combined documentation and project tracking.
Best for: Small teams, documentation-heavy workflows
Asana
Asana supports epic-style grouping through its Projects and Sections features. While it is not Agile-specific, its Portfolio views provide epic-level tracking across teams. The timeline view helps visualize dependencies between stories.
Best for: Cross-functional teams, non-engineering stakeholders
Frequently Asked Questions
Can a user story exist without an epic?
Yes, a user story can exist independently without being tied to an epic. Small, standalone improvements or bug fixes often exist as independent stories in the backlog. However, most teams find it helpful to group related stories under epics for organizational purposes, traceability, and progress tracking. If a story is truly self-contained and does not relate to a larger body of work, there is no requirement to force it into an epic.
How many user stories should an epic contain?
There is no strict rule, but most well-scoped epics contain between 5 and 15 user stories. Fewer than 3 stories may indicate the epic is too small and could simply be a story itself. More than 20 stories often suggests the epic is too large and should be split into multiple epics. The ideal number depends on the complexity of the feature and the granularity of your stories. The key principle is that each story should be independently deliverable within a single sprint.
Who is responsible for writing epics and user stories?
Product managers or product owners are typically responsible for writing epics, since epics represent strategic product initiatives that require business context and prioritization decisions. User stories can be written by product managers, but they are often co-created with the development team during backlog refinement sessions. Developers and designers contribute acceptance criteria and technical considerations. The best teams treat story writing as a collaborative activity rather than a top-down process.
How long should an epic take to complete?
Epics typically span multiple sprints and take anywhere from one to six months to complete, depending on the team size and scope of work. A common guideline is that an epic should be completable within a single quarter (roughly 3 months). If an epic is expected to take longer than a quarter, consider breaking it into smaller, phased epics that each deliver incremental value. This keeps the team motivated with regular completion milestones and allows stakeholders to see consistent progress.
What is the difference between an epic and a feature?
The terminology varies by framework and organization, but generally a feature is a distinct piece of product functionality that delivers value to users, while an epic is a large body of work that may encompass one or more features. In some frameworks like SAFe (Scaled Agile Framework), features sit between epics and stories in the hierarchy. In standard Scrum, the terms are sometimes used interchangeably. The important thing is that your team agrees on a consistent vocabulary and hierarchy.
Should user stories always follow the "As a... I want... So that..." format?
The "As a [user], I want [action], so that [benefit]" format is a widely recommended template because it forces teams to think about who benefits, what they need, and why. However, it is not a strict requirement. Some teams use alternative formats like job stories ("When [situation], I want to [motivation], so I can [outcome]") or simple declarative statements. The key principle is that every story should clearly communicate the user need, the desired functionality, and the value it provides, regardless of the exact template used.
How do you estimate effort for epics versus stories?
Stories are typically estimated using story points, T-shirt sizes (S/M/L/XL), or ideal hours during sprint planning or backlog refinement. These estimates are relatively precise because stories are small and well-defined. Epics, on the other hand, are estimated at a higher level using rough order of magnitude (ROM) estimates, often expressed in weeks or sprints rather than story points. As an epic is broken down into stories and work begins, the estimate becomes more accurate. Many teams use a "progressive elaboration" approach where epic estimates refine over time.
Can an epic span multiple teams?
Yes, epics frequently span multiple teams, especially in larger organizations. For example, an epic to "Launch a mobile payment feature" might involve the mobile team, the payments backend team, the security team, and the design team. In scaled agile frameworks like SAFe or LeSS, cross-team epics are managed through program-level planning events. When an epic spans teams, it is critical to identify dependencies early, establish clear ownership of sub-stories per team, and maintain communication through shared standups or integration meetings.
About the Author
Aditi Chaturvedi
·Founder, Best PM JobsAditi is the founder of Best PM Jobs, helping product managers find their dream roles at top tech companies. With experience in product management and recruiting, she creates resources to help PMs level up their careers.