# Sprints

> Plan, run and complete sprints — and handle the work that doesn't finish.

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

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

---
> **Pro and Premium**
>
> Sprints require Pro Unlimited or above.

A sprint is a fixed time box the team commits to. Its value comes entirely from
the box being **fixed**: same length every time, scope agreed at the start.

## Creating one

**Set the length**

    Two weeks suits most teams. One week for fast-moving work with short
    feedback loops; three or four only if your work genuinely cannot produce
    anything meaningful sooner.

> **Don't vary the length**
>
> Variable-length sprints make velocity meaningless, because you cannot
> compare one sprint's output to the next.

**Set the goal**

    One sentence describing what this sprint achieves. Not a task list — an
    outcome. It is what you use to decide whether mid-sprint requests belong.

**Pull work from the backlog**

    From the top, in order, until you reach capacity. See
    [Backlog](https://helpdesk.orangescrum.com/guide/cloud/agile/backlog).

**Start it**

    Once started, scope is fixed.

## Capacity

Capacity is your **recent velocity**, not your theoretical hours.

- **Use the last 3–5 sprints**: Take the average of what the team actually completed. That is your number.

- **Adjust for absence**: Two of six people away for a week is roughly a sixth off. Do not pretend otherwise.

- **Leave room**: Something always comes up. Planning to 100% guarantees a miss.

- **Don't plan on a new team's first sprints**: You have no velocity yet. Commit to less than feels right and measure.

> **Consistently missing the sprint is a planning problem**
>
> If the team finishes 60% of what it commits to, sprint after sprint, the fix
> is to commit to less — not to work harder. A sprint that is never met stops
> functioning as a commitment.

## Running it

The sprint board is the team's daily view. Statuses are your
[custom statuses](https://helpdesk.orangescrum.com/guide/cloud/tasks/custom-fields-and-statuses).

**Standup off the board**

    Right to left — start with what is closest to done. It biases the
    conversation toward finishing.

**Watch the burndown**

    Flat for three days means something is stuck. Find out what before the
    second week.

**Protect the scope**

    New requests go to the backlog for the next sprint. If something genuinely
    cannot wait, something else comes out — an explicit trade, not a silent
    addition.

## Mid-sprint changes

**Something urgent comes in**

    Ask whether it can wait two weeks. Most things can. If it truly cannot,
    remove work of equivalent size and say so — a sprint that quietly grows is
    a sprint that will be missed.

**A task turns out much bigger**

    Do not let it eat the sprint. Split it: deliver the part that fits, push
    the rest to the backlog.

**Someone is blocked**

    Raise it immediately. Blocked work in a fixed time box is the most expensive
    kind — the clock runs regardless.

**The team finishes early**

    Pull the next item from the top of the backlog. Do not invent work.

## Completing

When the sprint ends, complete it. Unfinished tasks are moved back to the
backlog or into the next sprint — the completion flow prompts you.

> **Don't extend a sprint to finish work**
>
> Extending destroys the fixed time box and the velocity data with it. End the
> sprint, carry the work over, and let the velocity number be honest.

Then do the two ceremonies that make the cycle worth anything:

- **Review** — show what was completed
- **Retrospective** — decide **one** thing to change next sprint

> **Tip**
>
> One change per retrospective. Five improvements means none of them get done or
> measured.

## Carryover

A little carryover is normal. A pattern is a signal:

| Pattern | Likely cause |
| --- | --- |
| Same task carried three sprints | Too big, or blocked and nobody has said so |
| Half the sprint carries over | Over-committing — cut capacity |
| Everything finishes on the last day | Work is not being started early enough |

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