# Agile overview

> Sprints, backlog, epics and the reports that tell you whether your process is working.

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

Source: https://helpdesk.orangescrum.com/guide/cloud/agile/overview

---
> **Pro and Premium**
>
> The agile framework — sprints, backlog, epics, velocity and burndown —
> requires Pro Unlimited or above. Epic and feature boards and Scrumban are
> Premium. See the [feature matrix](https://helpdesk.orangescrum.com/guide/cloud/plans/feature-matrix).

## Is agile right for this work?

Not every team should run sprints. Use them when:

- **Sprints fit**: Predictable capacity, work that can be sized, a team that plans together, and a need to forecast.

- **Sprints don't**: Reactive or support work, constantly shifting priorities, or a team of one. Use the [board](https://helpdesk.orangescrum.com/guide/cloud/views/kanban-board).

Running sprints badly is worse than not running them: a sprint that never
completes teaches the team that commitments are optional.

## The pieces

| Concept | What it is |
| --- | --- |
| **Backlog** | Everything not yet committed, ordered by priority |
| **Sprint** | A fixed time box the team commits to |
| **Epic** | A large body of work spanning sprints |
| **Feature** | A deliverable slice within an epic  |
| **Story / task** | The unit the team estimates and completes |
| **Velocity** | How much the team actually completes per sprint |
| **Burndown** | Remaining work over the sprint |

## The cycle

**Groom the backlog**

    Ongoing, not a one-off. Items near the top should be understood, estimated
    and ready. See [Backlog](https://helpdesk.orangescrum.com/guide/cloud/agile/backlog).

**Plan the sprint**

    Pull from the top of the backlog until you reach your capacity — which is
    your recent velocity, not your optimism. See
    [Sprints](https://helpdesk.orangescrum.com/guide/cloud/agile/sprints).

**Work the sprint**

    The sprint board is the team's daily view. Scope stays fixed; that is what
    makes the time box mean anything.

**Review and retrospect**

    Show what was completed. Then discuss what to change — and change one thing,
    not five.

**Read the numbers**

    Velocity and burndown over several sprints. See
    [Reports](https://helpdesk.orangescrum.com/guide/cloud/agile/reports).

## Scrumban 

A middle path: sprint cadence and planning, with WIP limits and continuous flow
inside the sprint. Suits teams that want predictability but face interruptions
that pure Scrum handles badly.

## Getting started without over-engineering

**Start with two-week sprints**

    Long enough to finish something, short enough to correct course. Change the
    length only after several sprints of evidence.

**Skip epics at first**

    Backlog and sprints alone. Add epics when you actually have work spanning
    several sprints.

**Estimate consistently, not accurately**

    Consistency is what makes velocity predictive. Perfect individual estimates
    are neither achievable nor necessary.

**Ignore velocity for three sprints**

    The first few numbers are noise. Only the trend means anything.

> **Velocity is not a productivity target**
>
> The moment it becomes a target, estimates inflate and the number stops
> measuring anything. Use it to forecast, never to compare teams or people.

## Where next

- [Backlog](https://helpdesk.orangescrum.com/guide/cloud/agile/backlog): Keeping it ordered and ready.

- [Sprints](https://helpdesk.orangescrum.com/guide/cloud/agile/sprints): Planning, running and completing them.

- [Epics and features](https://helpdesk.orangescrum.com/guide/cloud/agile/epics-and-features): Structuring work above the sprint.

- [Reports](https://helpdesk.orangescrum.com/guide/cloud/agile/reports): Velocity, burndown and what they actually tell you.