# Backlog

> Keep an ordered, ready list of work so sprint planning takes twenty minutes instead of two hours.

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

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

---
> **Pro and Premium**
>
> The backlog is part of the agile framework, available on Pro Unlimited and
> above.

The backlog is everything not yet committed to a sprint, ordered by priority.
Its job is simple: whenever you plan a sprint, the next thing to work on should
already be at the top and ready to start.

## What "ordered" means

A single ranked list, not buckets. If two items are both "high priority", one is
still above the other — someone has to decide, and it is better decided in
advance than in a planning meeting.

> **Tip**
>
> The top ten items should be genuinely ready. Below that, rough is fine.
> Refining item 200 is wasted work — it will change or be deleted before you get
> there.

## Ready to start

An item at the top of the backlog should be pullable without a conversation:

| Ready means | Not ready |
| --- | --- |
| The outcome is clear | "Improve the dashboard" |
| Acceptance criteria written | Nobody knows what done means |
| Estimated | No sense of size |
| Dependencies known | Blocked by something unfinished |
| Small enough for one sprint | Obviously several sprints of work |

> **Unready items poison sprint planning**
>
> If the team has to design the work during planning, planning takes hours and
> the estimates are guesses. Grooming is what prevents that.

## Grooming

A short, regular session — 30–60 minutes a week for most teams — where you:

**Re-rank the top**

    Priorities change. The order should reflect this week, not last quarter.

**Refine what's coming**

    Take the next sprint's worth and make it ready. Add criteria, estimate,
    identify dependencies.

**Split what's too big**

    Anything that cannot finish in one sprint gets broken down — or promoted to
    an [epic](https://helpdesk.orangescrum.com/guide/cloud/agile/epics-and-features).

**Delete aggressively**

    This is the step teams skip, and it is the most valuable one.

## Delete more than you think

A backlog of 400 items is not an asset. Nobody reads to the bottom, so anything
down there is invisible — while still costing attention every time you scroll
past it.

- **Delete it**: Untouched for six months, or nobody can explain why it matters. If it genuinely matters, it will come back.

- **Keep it**: A real commitment, or something you will act on this quarter.

> **Tip**
>
> A backlog you can read in one sitting is worth more than a comprehensive one
> you never open.

## Estimating

Estimate at the top of the backlog, not throughout. Items far down will change
before you build them.

Be **consistent rather than accurate** — velocity works as a forecast when
estimates are internally consistent, even if every number is systematically
wrong.

## From backlog to sprint

At planning, pull from the top until you hit capacity — your recent
[velocity](https://helpdesk.orangescrum.com/guide/cloud/agile/reports), not your optimism.

> **Don't cherry-pick from the middle**
>
> If the team routinely skips past top items to pull easier ones, the order is
> wrong or the top items are not ready. Fix that rather than working around it.

## Backlog and epics

Large work sits in the backlog as an [epic](https://helpdesk.orangescrum.com/guide/cloud/agile/epics-and-features)
until it is close enough to break down. That keeps big items visible without
cluttering the list with fifty speculative sub-items.

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