What Is an Epic in Agile? Definition, Examples, and How to Write One

Most teams can define a user story. Far fewer can draw a clean line between an epic, a feature, and a theme – or explain why that distinction matters when sprint planning breaks down. This article gives you a precise definition, a practical breakdown of the hierarchy, and a real-world healthcare IT scenario that shows how epics function under pressure.

What Is an Epic in Agile? The Exact Definition

An epic is a large body of work that cannot be delivered within a single sprint and must be decomposed into smaller user stories before a team can act on it. Mike Cohn, who co-founded the Scrum Alliance and formalized the term in User Stories Applied for Agile Software Development (2004), described it simply: when a story is too large, it becomes an epic.

The Agile Alliance’s current definition extends that: an epic is a large user story that either cannot be delivered as defined within a single iteration, or is large enough to be split into smaller stories. Neither definition imposes a fixed size threshold. The only test is whether the work fits inside a sprint as-is. If it doesn’t, it’s an epic.

That simplicity creates a problem in practice. Teams using Scrum or SAFe often treat epics as permanent containers or project labels, which is a misuse. An epic should have a start, an end, and a measurable outcome. Once its stories are delivered and the business value is realized, the epic closes.

Epic vs. Feature vs. User Story: The Agile Hierarchy

Confusion between these three terms causes planning failures more often than any backlog tool ever fixed. The hierarchy differs slightly between frameworks, so it helps to look at both.

In Scrum and Kanban

Classic Scrum doesn’t formally define the epic-feature layer. The hierarchy is informal: themes group epics, epics group user stories. A theme is a broad strategic goal. An epic is a large initiative under that goal. A user story is a single, sprint-sized unit of work. Teams often use these terms in tools like Jira without referencing any formal specification.

In SAFe (Scaled Agile Framework)

SAFe introduced a more structured hierarchy tied to organizational levels:

In SAFe, epics require a Lean business case and go through a portfolio Kanban system before approval. That’s a meaningful gate – it prevents teams from executing large initiatives without funding decisions. A feature, by contrast, is sized to fit within a Program Increment and doesn’t need that approval layer.

The practical difference matters when your organization scales. On a single-team project, the epic-feature distinction is overhead. On a 200-person program with five Agile Release Trains, that distinction keeps the portfolio aligned with strategy.

Business Epics vs. Enabler Epics

Both Scrum and SAFe recognize two categories of epics, and understanding them prevents misclassification.

A business epic delivers direct customer-facing value. It maps to a revenue goal, a regulatory requirement, or a product capability. Examples: patient portal self-scheduling, claims adjudication automation, or a mobile banking onboarding flow.

An enabler epic supports the technical foundation that business epics depend on. It doesn’t produce visible features, but it’s not optional. Examples: migrating a monolith to microservices, implementing HL7 FHIR R4 endpoints, or building a CI/CD pipeline to support continuous deployment.

In healthcare IT, enabler epics routinely surface before a new module rollout. A hospital system can’t deliver an SDLC-compliant patient data exchange feature without first establishing FHIR-compliant APIs. The API work is an enabler epic. Skipping it, or hiding it inside a business epic to make the backlog look cleaner, is how integration failures happen in Go-Live week.

How to Write an Epic: Structure and Acceptance Criteria

A well-written epic has four components: a short name, a narrative statement, acceptance criteria at the epic level, and a definition of done that confirms when to close it.

The Epic Narrative

Many teams write epics the same way they write user stories. That works for smaller epics. The format:

For complex, multi-team epics, the narrative expands into a Lean business case. SAFe’s template includes: the epic hypothesis, a leading indicator of value, a non-functional requirement statement, and the minimum viable product (MVP) definition. This format forces the team to articulate what success looks like before writing a single story.

Epic-Level Acceptance Criteria

Epic acceptance criteria are not story acceptance criteria. They operate at outcome level, not feature level. They answer: how will we know the epic delivered its intended value?

An example in a financial services context: a payments modernization epic might have acceptance criteria stating that ACH transaction processing latency drops below 500ms at the 95th percentile, and that all transactions produce an audit log entry conforming to the existing schema. Those are outcome-level criteria. Individual stories under that epic will have their own technical acceptance criteria, but the epic criteria govern the whole.

Scenario: Epic Decomposition in a Healthcare IT Implementation

Consider a regional hospital network migrating from a legacy scheduling system to a modern EHR platform. The program leadership defines an epic: “Enable patient self-scheduling across all ambulatory clinics.”

At the portfolio level, this epic has a Lean business case: reduce call-center volume by 30%, improve patient no-show rates through automated reminders, and meet CMS interoperability requirements under the 21st Century Cures Act. The epic owner maps it to a strategic investment theme around patient access.

Under that epic, the product manager on the Agile Release Train identifies five features:

1. Patient portal authentication and account management
2. Real-time appointment slot visibility via FHIR R4 Slot resource
3. Automated SMS and email reminder workflows
4. Waitlist and cancellation handling
5. Reporting dashboard for clinic operations

Each feature gets decomposed into user stories by individual teams during PI Planning. The authentication feature alone produces twelve stories: account creation, password reset, MFA enrollment, session timeout logic, HIPAA-compliant audit logging for login events, and more.

This is also where the edge case surfaces: the legacy system holds appointment data in a proprietary format with no FHIR mapping. An enabler epic gets created in parallel: “Implement HL7 FHIR R4 Schedule and Slot resources for legacy data migration.” Without it, the self-scheduling business epic cannot deliver. Teams that skip this step often discover it during STLC execution – when integration testing fails and the release window has already been committed to executive stakeholders.

Epic vs. Feature vs. User Story: Side-by-Side Comparison

Epic Decomposition: How to Break It Down Without Losing Scope

Decomposing an epic is where most teams make their first mistake. They split by technical layer – one story for the back-end, one for the front-end, one for the database – instead of splitting by user value. Layer-based splits create dependencies and prevent any single story from delivering working software on its own.

BABOK v3 and the broader requirements engineering community both emphasize traceability: each decomposed story should trace back to a specific business objective. If you can’t draw that line, the story doesn’t belong in the epic. Karl Wiegers, in Software Requirements, makes the same point in a different vocabulary: requirements at every level of granularity must connect to a documented business need. Epics that become permanent backlog holders – never closing, never delivering – are usually epics where that connection was never established.

Splitting Strategies That Work

Bill Wake’s INVEST criteria apply to stories, not epics directly, but the decomposition goal is to eventually produce stories that meet it. When splitting, use these approaches:

Split by workflow step. If the epic covers an end-to-end process, each major step becomes a feature or a large story. A claims processing epic might split into: intake, eligibility verification, adjudication, payment, and denial management.

Split by user type. Different roles have different needs within the same capability. An admin view and a clinician view of the same patient data are separate stories, even if they share the same API.

Split by data variation. A report epic might split by report type: summary, detail, and export. Each delivers value independently.

Split by acceptance criteria. If your epic has eight outcome-level criteria, each criterion may produce one or more features. This is particularly clean for compliance-heavy work, where each HIPAA or HITECH requirement maps to a discrete deliverable.

The Role of the Business Analyst in Epic Ownership

On most enterprise Agile programs, the BA operates between the portfolio and team levels. They don’t own the epic – that’s the Epic Owner or Product Manager – but they’re the ones who make decomposition possible.

In practice, the BA is responsible for eliciting and documenting the epic’s functional scope, mapping it to business capabilities, and maintaining traceability as stories are written and refined. They run story-writing workshops, challenge acceptance criteria that are too vague to test, and flag gaps between what the epic promises and what the sprint backlog actually delivers.

This role becomes especially visible during QA activities. When a tester asks why a story has no clear definition of done, the gap usually traces back to an epic that was never properly decomposed. The epic acceptance criteria were never translated into testable story-level criteria. The BA who owns that traceability chain is the one who prevents that gap from becoming a defect in production.

BABOK v3’s knowledge area on Requirements Life Cycle Management is explicit: requirements must be maintained across their entire lifecycle, including when they’re decomposed from one level to another. Epics are requirements. Their traceability doesn’t disappear when they’re split into stories.

Common Epic Anti-Patterns

These patterns appear on real projects and cause real delays. Naming them prevents the instinct to rationalize them.

The permanent epic. An epic that’s been open for 18 months is not an epic – it’s a project masquerading as one. Either the scope was never bounded, or nobody has authority to close it. Both are governance failures.

The technical epic. “Refactor authentication service” is not an epic. It’s a technical task. Unless it connects to a business outcome – security incident reduction, compliance with SOC 2 requirements, enabling a new product feature – it has no epic-level justification. Put it in an enabler epic with a stated hypothesis.

The vanity epic. Epics written to look good in a portfolio roadmap, with no decomposable stories underneath them, are placeholders, not commitments. If a team can’t estimate the first three stories, the epic isn’t ready to be committed.

The layer epic. “Back-end API work for Q3” is a component grouping. It has no user value statement. Splitting by architectural layer creates dependencies between teams and prevents independent delivery. This is particularly common in organizations transitioning from waterfall to Agile, where the old project structure survives inside the new vocabulary.

Epic Tracking: Burndown, Metrics, and Stakeholder Visibility

An epic that can’t be tracked is an epic that can’t be managed. Teams need two types of visibility: progress toward closure and health of the decomposition.

Epic burndown charts track the remaining story points (or story count) in an epic over time. If the chart is flat or growing, either teams are not completing stories or new scope is being added faster than work is being finished. Both conditions need a conversation with the Epic Owner, not just a tool update.

In SAFe, the program PI Objectives and ART sync ceremonies provide the cadence for that conversation. Teams report feature-level progress, and the Epic Owner aggregates that into portfolio-level status. The key metric at the epic level is not velocity – it’s the leading indicator defined in the Lean business case. For a patient access epic, that might be self-scheduled appointments as a percentage of total bookings, measured every two weeks.

Stakeholders outside the development teams should never need to read sprint reports to understand epic status. The Epic Owner’s job is to translate sprint-level activity into business-outcome language. “We completed three features this PI” means nothing to a CFO. “Patient self-scheduling is now live in seven of twelve clinic locations” does.

When Epics Don’t Work: Constraints You’ll Actually Face

Ideal Agile environments are rare. On most programs, epics operate under constraints that the framework documentation doesn’t address.

Legacy systems impose decomposition ceilings. If the back-end can only be changed during quarterly maintenance windows, story-level granularity is irrelevant – delivery happens in batches regardless of how the backlog is organized. The epic structure still has value for planning and visibility, but the sprint rhythm doesn’t reflect actual delivery cadence.

Compliance requirements compress the flexibility that epics are designed to provide. A HIPAA-driven data migration epic can’t ship features incrementally if the security review is conducted once at the end. The team may write incremental stories, but the release is a waterfall event. Recognizing this distinction prevents false confidence in the backlog.

Cross-functional politics affect epic ownership more than any framework acknowledges. In organizations where product management and IT report to different executives, the Epic Owner may have accountability without authority. They can’t get features prioritized across ARTs because each ART’s Product Manager answers to a different budget holder. SAFe addresses this with portfolio governance, but the organizational design has to support it – the framework alone doesn’t fix a siloed org chart.

The next time a project is struggling with scope creep or sprint planning that never converges, check the epics first. Scope creep usually isn’t random – it’s a signal that an epic was never properly bounded, its acceptance criteria were too vague to enforce, or decomposition happened without traceability. Fix the epic definition before fixing the sprint.

Suggested external authoritative references:
1. Scaled Agile Framework – Epic (scaledagileframework.com) – the canonical SAFe definition, Lean business case template, and portfolio Kanban guidance.
2. Agile Alliance Glossary – Epic (agilealliance.org) – framework-neutral definition with historical context from Mike Cohn’s original usage.