For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/agile/sprints.md.
Sprints
Plan, run and complete sprints — and handle the work that doesn't finish.
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.
Start it
Once started, scope is fixed.
#Capacity
Capacity is your recent velocity, not your theoretical hours.
Take the average of what the team actually completed. That is your number.
Two of six people away for a week is roughly a sixth off. Do not pretend otherwise.
Something always comes up. Planning to 100% guarantees a miss.
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.
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 |
Velocity, burndown and what they actually tell you.