A Scrum primer · Part 3 of 5
The Sprint and the Scrum Events
The Sprint and the four events inside it: what each event is for, its timebox, how the timeboxes scale for a shorter Sprint, and the common ways each event goes wrong.
Why Scrum has events
Each Scrum event gives the team a set time to inspect something and to adapt it. The events put inspection on a regular schedule, so that it happens even when the team is busy. They also replace most other meetings. The team holds the events at the same time and place each Sprint. Nobody has to plan a meeting from scratch, and the rhythm becomes a habit.
Every event has a timebox, which is a maximum length. An event can end early when it achieves its purpose. It must not run longer. The timebox keeps the events short and focused, and it keeps the team’s time for the work itself.
Scrum has five events. The Sprint is the container for the other four: Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective.
The Sprint
The Sprint sets the pulse of Scrum. It is a fixed period of one month or less in which the team turns ideas into value. The length stays the same from Sprint to Sprint, so the team can compare one Sprint with another. A new Sprint starts immediately after the previous one ends. There is no gap between Sprints for “integration” or “hardening”. All the work of the team happens inside a Sprint, the four events included.
During the Sprint, four rules apply:
- Nobody makes changes that put the Sprint Goal at risk.
- Quality does not go down.
- The team refines the Product Backlog as needed.
- The team can clarify the scope and renegotiate it with the Product Owner as it learns more.
You can think of each Sprint as a short project. A long Sprint has problems. The Sprint Goal can become invalid before the Sprint ends, complexity goes up, and so does risk. Shorter Sprints give the team more learning cycles and limit the cost of a wrong turn.
The Product Owner can cancel a Sprint if its Sprint Goal becomes obsolete. Only the Product Owner has this authority. In practice, a cancellation is rare, because a short Sprint seldom loses its purpose before it ends.
The timeboxes at a glance
The Scrum Guide gives the maximum length of each event for a Sprint of one month. For a shorter Sprint, the Guide says that the event is usually shorter. The Daily Scrum is the exception. It is 15 minutes whatever the Sprint length.
| Event | Timebox for a one-month Sprint | Purpose |
|---|---|---|
| Sprint | One month or less, fixed | The container for all the work and for the other four events |
| Sprint Planning | 8 hours at most | Agree why the Sprint matters, what to do, and how to do it |
| Daily Scrum | 15 minutes, every working day | Inspect progress toward the Sprint Goal and adapt the plan |
| Sprint Review | 4 hours at most | Inspect the outcome with stakeholders and decide what comes next |
| Sprint Retrospective | 3 hours at most | Find ways to improve quality and effectiveness |
Sprint Planning
Sprint Planning starts the Sprint. The whole Scrum Team takes part, and the team can invite other people to give advice. The Product Owner makes sure that the attendees come prepared. They discuss the most important Product Backlog items and how those items relate to the Product Goal. Sprint Planning answers three questions.
- Topic one: why is this Sprint valuable?
- The Product Owner proposes how the product could increase its value and usefulness in this Sprint. The whole Scrum Team then works together to define a Sprint Goal. The Sprint Goal tells stakeholders why the Sprint is valuable. The team must agree on the Sprint Goal before Sprint Planning ends.
- Topic two: what can be Done this Sprint?
- The Developers select items from the Product Backlog to include in the Sprint. They talk with the Product Owner about these items, and they can refine them during the discussion. Past performance, current capacity and the Definition of Done help the Developers make a realistic selection.
- Topic three: how will the chosen work get done?
- The Developers plan the work that turns each selected item into an Increment that meets the Definition of Done. Teams often split the work into pieces of one day or less. How to do the work is the Developers’ decision alone.
The result of Sprint Planning is the Sprint Backlog: the Sprint Goal, the selected items, and the plan to deliver them.
The Daily Scrum
The Daily Scrum is a 15-minute event for the Developers. Its purpose is to inspect progress toward the Sprint Goal and to adapt the Sprint Backlog when necessary. The team holds it at the same time and place every working day of the Sprint. If the Product Owner or the Scrum Master works on items in the Sprint Backlog, they take part as Developers.
The Developers choose the structure and the technique. The 2020 Guide no longer names the three questions that older versions used as an example. Any format is fine if it focuses on progress toward the Sprint Goal and ends with a plan for the next day of work.
The Daily Scrum improves communication and exposes impediments early. It also lets the team make decisions quickly, and it often removes the need for other meetings. The Developers can adjust their plan at any time during the day. The Daily Scrum is not the only moment for that.
The Sprint Review
The Sprint Review inspects the outcome of the Sprint and decides on future adaptations. The Scrum Team presents its results to key stakeholders, and the group discusses progress toward the Product Goal. The attendees then talk about what changed in their environment and what to do next. The Product Backlog can change as a result.
The Sprint Review is a working session. It is not a presentation to an audience. The team shows real, working product, and the stakeholders give real feedback. The Sprint Review is the second-to-last event of the Sprint.
The Sprint Review is not a gate for release. A team can deliver an Increment to users before the end of the Sprint, and many teams release several times in one Sprint.
The Sprint Retrospective
The Sprint Retrospective concludes the Sprint. Its purpose is to plan ways to improve quality and effectiveness. The Scrum Team inspects how the last Sprint went. It looks at people, interactions, processes, tools and the Definition of Done. It discusses what went well, what problems it met, and how it solved them or failed to.
The team then chooses the most helpful changes to improve its effectiveness. It deals with the most important improvements as soon as possible. A team can even add an improvement to the Sprint Backlog of the next Sprint.
Refinement is not an event
Product Backlog refinement is an ongoing activity, not a Scrum event. The team breaks down items, adds detail, and sizes them throughout the Sprint. The next part of this primer covers refinement with the artifacts, because refinement is how the Product Backlog stays ready.
Common anti-patterns
The Scrum Guide does not list anti-patterns. The patterns below come from common experience with Scrum teams.
This primer follows the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland and explains it in our own words. Read the Guide itself at scrumguides.org. The Scrum Guide is available under the Creative Commons Attribution-ShareAlike 4.0 license. Scrum.org and Scrum Inc. did not write or review this page.