How big should an epic be?

An epic typically represents 2-12 weeks of work for a team, comprising 5-20 user stories. If an epic would take longer than a quarter to complete, consider splitting it into smaller epics. If it can be completed in a single sprint, it is probably a story, not an epic. The right size depends on team context and planning horizon.

When should you decompose an epic into stories?

Decompose epics progressively as they approach development. Break down the first few stories in detail for the upcoming sprints, leave later stories at a higher level. This avoids wasting time on detailed planning for work that may change. Backlog refinement is the primary ceremony for epic decomposition.

How do you track epic progress?

Track epic progress through the completion percentage of child stories (by count or story points), epic burndown charts showing remaining work over time, and status updates on the overall business objective. Some teams also track the percentage of acceptance criteria met at the epic level.

Book Free Assessment Calculator

Epic

Also known as:featurecapabilityinitiative

A large body of work that can be broken down into smaller user stories, representing a significant feature or capability that typically spans multiple sprints to complete.

In-Depth Explanation

An epic is a large user story that is too big to complete in a single sprint and needs to be decomposed into smaller, deliverable stories. Epics represent major features, capabilities, or initiatives that contribute to strategic objectives.

Epic characteristics:

Too large for a single sprint (typically weeks or months of work)
Comprises multiple related user stories
Represents a meaningful business capability or outcome
Has a clear business objective and success criteria
Evolves as the team learns more through implementation

Epic hierarchy:

Theme/Initiative: Strategic business objective (e.g., "Improve customer self-service")
Epic: Major feature or capability (e.g., "Online account management portal")
User story: Specific, deliverable functionality (e.g., "As a customer, I can view my invoices")
Task: Technical work within a story (e.g., "Create invoice API endpoint")

Writing effective epics:

Define the business objective clearly
Describe the target users and their needs
Outline the high-level scope without over-specifying details
Include success metrics or KPIs
Identify key assumptions and risks
Break down into stories progressively (not all at once)

Epic management best practices:

Track epic progress through the completion of child stories
Use epic burndown charts to visualise progress
Review and adjust epic scope at regular intervals
Communicate epic status to stakeholders
Close epics when the business objective is met (not necessarily when all stories are done)
Avoid too many open epics simultaneously (focus is important)

Business Context

Epics provide a bridge between strategic initiatives and day-to-day development work, enabling teams to deliver large features incrementally while maintaining a clear connection to business objectives.

How Clever Ops Uses This

Clever Ops structures client projects around epics that map to business objectives, decomposing them into deliverable stories that can be completed in sprints. This approach gives Australian businesses visibility of both the big picture and the detailed progress of their projects.

Example Use Case

"An epic "Automated onboarding" is broken into 12 user stories covering account creation, document upload, identity verification, and welcome communications, delivered over 4 sprints."