For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/agile/epics-and-features.md.
Epics and features
Structure work above the sprint without losing sight of what is actually shipping.
Epics on Pro, feature board on Premium
Epics require Pro Unlimited. The epic and feature board, and approvals for epics and features, are Premium. See the feature matrix.
#The hierarchy
| Level | Spans | Example |
|---|---|---|
| Epic | Several sprints | "Self-service onboarding" |
| Feature | Roughly a sprint | "Email verification flow" |
| Story / task | Days | "Send verification email" |
You do not need all three. Most teams do fine with epics and tasks; add features when an epic is large enough that its middle layer is genuinely useful.
#Epics
An epic is a body of work too large for one sprint, held together by a shared outcome.
"Reduce checkout abandonment" — one outcome, several sprints, clear when it is done.
"Frontend work" — a category, not an outcome. It will never be finished.
#Keeping epics honest
Give it a definition of done
An epic without one runs forever, absorbing loosely related work.
Don't break it all down at once
Detail the next sprint's worth. Detailing sprint five's work now guarantees rewriting it.
Close it when the outcome is met
Not when every idea anyone ever attached to it is done.
Cap how many are open
Three or four active epics per team. Twelve means nothing is being focused on.
Epics that never close are the common failure
An epic open for a year, still collecting tasks, has become a folder. It tells you nothing about progress. Close it and start a new one with a fresh outcome.
#Features Premium
A feature is a deliverable slice of an epic — roughly a sprint's worth, independently valuable.
The test: could you ship this on its own and have it mean something to a user? If not, it is a task, not a feature.
#The feature board
A board at feature level rather than task level. It is the right view for a stakeholder conversation, where individual tasks are too granular and the epic is too coarse.
#Approvals Premium
Epics and features can require approval before work starts. Useful where budget or compliance sign-off gates delivery.
Tip
Add approvals only where a real gate exists. An approval step that is always granted teaches everyone to route around it.
#Scaled agile
For several teams working toward a shared outcome, epics and features provide the layer above individual team sprints — and programs group the projects those teams work in.
Structure is not coordination
A tidy hierarchy does not make teams talk to each other. The cross-team dependencies still need to be recorded and actively managed.
#Start simple
Sprints and tasks only
Run this until it visibly stops working.
Add epics when work spans sprints
When you keep asking "how is the onboarding work going?" and cannot answer from a sprint board.
Add features only if the middle layer helps
Most teams never need it. Adding it "for completeness" creates overhead without insight.