For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/agile/overview.md.
Agile overview
Sprints, backlog, epics and the reports that tell you whether your process is working.
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.
#Is agile right for this work?
Not every team should run sprints. Use them when:
Predictable capacity, work that can be sized, a team that plans together, and a need to forecast.
Reactive or support work, constantly shifting priorities, or a team of one. Use the 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 Premium |
| 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.
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.
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.
#Scrumban Premium
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.