What Is a Sprint in Agile?

How a sprint works

In Scrum, the Sprint is the main timebox and the container for every other event. Sprint Planning, the Daily Scrums, the Sprint Review and the Sprint Retrospective all happen inside it. A new sprint starts right after the previous one ends; there is no gap for hardening or planning in between.

The 2020 Scrum Guide sets a few rules for the time in between:

• No changes are made that would put the Sprint Goal at risk.
• Quality doesn’t drop to hit a date.
• The Product Backlog is refined as needed. Refinement is an ongoing activity, not a formal event.
• Scope can be clarified and renegotiated with the Product Owner as the team learns more.

How long should a sprint be?

One month or less, and the same length every time. Consistent length is what makes sprints useful for planning: the team learns how much it can finish in one, and stakeholders know when they’ll next see progress.

Shorter sprints mean faster feedback and less work at risk if the direction is wrong, at the cost of relatively more time in planning and review. Longer sprints leave room for bigger pieces of work but delay feedback and let complexity and risk build up. Pick the shortest length in which the team can regularly finish something valuable, and change it deliberately rather than stretching a sprint that is running late.

Is a sprint always 2 weeks?

No. Two weeks is a common choice because it balances feedback against planning overhead, but the Scrum Guide only sets the upper limit of one month. One-week sprints suit teams whose priorities change quickly; three- or four-week sprints can suit work with longer feedback loops.

Whatever length you choose, don’t extend a sprint to fit unfinished work. If the work doesn’t fit, it goes back to the Product Backlog and the next sprint starts on time.

What happens during a sprint, start to finish

The Scrum Guide gives maximum timeboxes for a one-month sprint. Shorter sprints usually need less time for each event.

• Sprint Planning (up to 8 hours): the team agrees why the sprint is valuable (the Sprint Goal), what it can get done and how. The result is the Sprint Backlog.
• Daily Scrum (15 minutes): the Developers inspect progress toward the Sprint Goal and adjust their plan for the next day.
• The work: the Developers build, test and integrate items to the Definition of Done, which is the commitment for each Increment. More than one Increment can be delivered within a sprint.
• Sprint Review (up to 4 hours): the team and stakeholders look at what was done and decide what to adapt in the Product Backlog. It is a working session, not a release gate.
• Sprint Retrospective (up to 3 hours): the team looks at how it worked, including people, process, tools and the Definition of Done, and picks improvements. The retrospective ends the sprint.

What happens at the end of a sprint?

The sprint ends when its timebox runs out, not when the work is finished. Items that meet the Definition of Done are part of the Increment. Items that don’t can’t be presented as done; they go back to the Product Backlog, where the Product Owner decides whether and when to pick them up again.

The Sprint Review and Retrospective close the loop, and the next Sprint Planning starts right away. A sprint can be cancelled early only if its Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it.

Sprint vs iteration, and sprints in Kanban

Sprints and iterations are close cousins. Kanban works differently, though teams often combine it with sprints.

• Sprint: Scrum’s term for a fixed timebox of one month or less, with a Sprint Goal and defined events.
• Iteration: the general term for a timeboxed development cycle, used in Extreme Programming and SAFe. Every sprint is an iteration; not every iteration follows Scrum’s rules.
• Kanban: no sprints. Work flows continuously and is pulled as capacity frees up, with WIP limits controlling how much is in progress at once.
• Combining them: Scrum teams can use Kanban practices inside their sprints, and Scrum.org publishes a Kanban Guide for Scrum Teams. Teams that add sprint-style planning and review cadences to a Kanban board often call the result Scrumban.