Sprint Planning
At the start, the team clarifies why the Sprint is valuable, what can be done and how. The result is the Sprint Goal.
Insights · Agile organisation
How a Sprint of one to four weeks runs, what happens in the show and tell with the business and how several teams provide deliverable results continuously with Scrum@Scale.
By Michele Mangieri · Updated
In short
A Sprint in Scrum lasts one month or less, usually one to four weeks. It starts with Sprint Planning, a 15-minute Daily Scrum follows every day, and it ends with the Sprint Review as a show and tell with the business, followed by the retrospective. Finished results may be delivered during the Sprint.
Events
A Sprint lasts one month or less, in practice usually one to four weeks. Its length stays the same so that a reliable rhythm develops. All events take place within the Sprint.
At the start, the team clarifies why the Sprint is valuable, what can be done and how. The result is the Sprint Goal.
Every day for 15 minutes, at the same time and place. The developers inspect progress towards the Sprint Goal and adapt their plan.
At the end, the team shows the business and other stakeholders what is done and discusses it with them: what fits, what is missing, what comes next? The Scrum Guide treats the review as a working session, not just a presentation.
The team inspects how it worked: collaboration, processes, tools and the Definition of Done. The most important improvements go into the next Sprint.
An ongoing activity: Product Backlog items are broken down and clarified until they fit into a Sprint.
Example
This is what a two-week Sprint looks like for many teams. Each team sets its own times.
Sprint length
Fastest feedback, but a lot of coordination relative to the work. Good when requirements change often. Planning up to about 2 hours, review about 1 hour, retrospective about 45 minutes.
A common rhythm: enough time for a usable result, feedback every ten working days. Planning up to about 4 hours, review about 2 hours, retrospective about 1.5 hours.
Fits when results need more lead time, for example for business testing. Planning up to about 6 hours, review about 3 hours, retrospective about 2 hours.
The Scrum Guide's upper limit. The longer the Sprint, the more likely the Sprint Goal becomes outdated along the way and the higher the risk. Planning up to 8 hours, review 4 hours, retrospective 3 hours.
The times are maximums from the 2020 Scrum Guide for a one-month Sprint; for shorter Sprints they are given proportionally as a rule of thumb.
With several teams
When several teams work on one product, a deliverable result only exists once their work fits together. Scrum@Scale and proven engineering practices offer several ways to get there.
In an S/4HANA transformation we automated UAT and regression tests so that results are ready for acceptance sooner. As Scrum Master and facilitator between business and IT, we have seen that the rhythm only holds when the business and stakeholders actually attend the review.
Want to bring several teams into one rhythm? To Workshop Facilitation →
Sources: The Scrum Guide, November 2020, Ken Schwaber and Jeff Sutherland; The Scrum@Scale Guide, version 2.1, February 2022, Jeff Sutherland and Scrum Inc.; both under the CC BY-SA 4.0 licence. Scrum@Scale is a registered trademark of Scrum Inc. maxClaint is an independent advisory firm and not affiliated with Scrum Inc.
Frequently asked questions
One month or less, in practice usually one to four weeks. The length stays the same so that a rhythm develops. If a Sprint is too long, the Sprint Goal can become outdated along the way and risk increases.
It is a common name for the Sprint Review. The team shows the business and other stakeholders its working result, the business tries it out and gives feedback. The Scrum Guide treats the review as a working session in which the next steps are decided.
Yes. Several increments may be created and delivered within a Sprint. The Sprint Review is not a gate for release. The condition is that the result meets the Definition of Done.
With one shared Definition of Done, an integrated increment in the Scrum of Scrums and automated deployment. Feature toggles separate deployment from release. Impediments go via the Scaled Daily Scrum to the Executive Action Team.
You describe the decision ahead. We tell you which package fits, or that none does.