# Epics and features

> Structure work above the sprint without losing sight of what is actually shipping.

> For the complete documentation index, see [llms.txt](https://helpdesk.orangescrum.com/llms.txt).

Source: https://helpdesk.orangescrum.com/guide/cloud/agile/epics-and-features

---
> **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](https://helpdesk.orangescrum.com/guide/cloud/plans/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.

- **A good epic**: "Reduce checkout abandonment" — one outcome, several sprints, clear when it is done.

- **A bad epic**: "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 

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 

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](https://helpdesk.orangescrum.com/guide/cloud/projects/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](https://helpdesk.orangescrum.com/guide/cloud/tasks/subtasks-and-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.

- [Backlog](https://helpdesk.orangescrum.com/guide/cloud/agile/backlog): Where epics live before they are broken down.

- [Reports](https://helpdesk.orangescrum.com/guide/cloud/agile/reports): Progress across epics and sprints.