The Purpose of the Five Scrum Events
There are five events in Scrum. But just going through the motions and having each of the events on the calendar is not enough. To get the most out of Scrum, your team needs to understand the purpose behind each of the five events.
The purpose of the Sprint is to deliver a Done, usable increment that meets the Sprint Goal.
Let’s start with the Sprint itself. The Sprint is not a meeting. It’s not even a get-together. It’s a container that includes all of the other events. Those words might have tempted you to skip over this section, but there are some things that you need to know about the Sprint.
The Sprint has a timebox of one month. While the duration of the Sprint is up to your team, it cannot be more than one month. How long should the Sprint be? It should be just long enough to deliver a Done, usable increment and no more.
Quality does not decrease during the Sprint. We do not cut corners to deliver all of the Product Backlog items we selected at Sprint Planning.
Everything happens in the Sprint. Refinement of the Product Backlog for the next Sprint happens during the Sprint. Sprint Planning, the Daily Scrum, Sprint Review and the Sprint Retrospective all occur within the sprint.
There are no special Sprints. There are no “testing” or “release” sprints. Instead, each Sprint results in a Done, potentially releasable Increment of valuable product.
The Purpose of Sprint Planning is to plan the work for the upcoming Sprint.
During the Sprint Planning event, your Scrum Team decides what Product Backlog items you will deliver during the Sprint and how you will produce them. Your team creates a goal for the Sprint that describes why you are delivering these Product Backlog items, which provides focus for the Sprint.
The Sprint Planning meeting is not just about selecting Product Backlog items; it’s about planning the work of the Sprint. If your team is not discussing how they will produce the selected Product Backlog items, they are not making the most of the Sprint Planning event. Does this mean you need to plan out every day of the Sprint? No, it doesn’t. The Scrum Team should plan just enough to get started. The team creates their Sprint plan in the Sprint Backlog at the Sprint Planning event. However, it evolves during the Sprint as more becomes known.
For example, imagine that a Scrum Team is painting a room. At the Sprint Planning meeting, they decide that Bob will buy the paint and the brushes, Sue will paint the north wall, Bill will paint the south wall, and so on. During the Sprint, the team realizes that they have purchased the wrong paint color. In response, they add a task to the Sprint Backlog to have Shelly return to the paint store for the right color. The team made the initial plan at the Sprint Planning event, but the Sprint Backlog emerged over time as the work requirements unfolded.
The Sprint Planning event has a timebox of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter as well.
The purpose of the Daily Scrum is to increase the likelihood of delivering a Done, usable increment that meets the Sprint Goal.
At the Daily Scrum, Developers monitor their progress towards delivering a Done, usable increment that meets the Sprint Goal, and they plan their work for the next 24 hours.
The Daily Scrum has a timebox of 15 minutes. It’s crucial to respect that timebox. I made a mistake once of allowing the Daily Scrum to last an hour. No one came to the next Daily Scrum.
The Daily Scrum is not a problem-solving event. It’s a place for your team to identify (but not solve) impediments. In cases where a problem needs additional time to sort out, the necessary people should meet as soon as possible (perhaps immediately after the Daily Scrum) to problem-solve.
The purpose of the Sprint Review is for the team to discuss what they completed during the Sprint and collaborate on what to do next.
The Sprint Review is an opportunity for the Scrum Team and stakeholders/customers to inspect what the team delivered and its progress towards the Product Goal and adapt accordingly. The Sprint Review is not a demo - although a demo may be on the agenda. Instead, this is a key inspect-and-adapt event where your team gathers feedback the Product Owner may use to update the Product Backlog and product forecast.
The timebox for the Sprint Review is four hours. This timebox exists to respect attendees' time and ensure that the meeting remains productive.
The purpose of the Sprint Retrospective is to improve the Scrum Team’s effectiveness.
The Retrospective is the final event in a Sprint. The team discusses how the Sprint went regarding individuals, interactions, processes, tools, and their Definition of Done. All Scrum Team members attend, including the Scrum Master, Developers and the Product Owner. Like all the events in Scrum, there is no predefined agenda. However the event unfolds, it is essential that by the end of the Retrospective, the Scrum Team has identified one or two improvements they will make to their processes, tools, interactions or their Definition of Done. Why just one or two? Because you can’t do everything at once, and a series of small, incremental changes is more impactful than one extensive “rewrite” of your team’s processes.
The timebox for the Sprint Retrospective is three hours, although the Retrospective is usually shorter for shorter Sprints.
To get the most out of Scrum, Scrum Team members must understand the purpose behind each event. Sprint Planning is not just about selecting Product Backlog items; it’s about planning the work of the Sprint. The Daily Scrum is not about mechanically answering the three questions (what did you do today, what will you do tomorrow, and do you have any impediments?). It’s about increasing the likelihood of delivering a Done increment that meets the Sprint Goal. The Sprint Review is not a demo; it’s about discussing what you completed and collaborating on what to do next. And the Sprint Retrospective is not a venting session; it’s a chance for the Scrum Team to improve how they work together.
To learn more about the purpose of each of the Scrum events, signup for Rebel Scrum’s Applying Professional Scrum class. And may the force (and Scrum) be with you.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
- Applying Professional Scrum
- Introductory class for those new to Scrum
- Professional Scrum Master
- Geared towards Scrum Masters coaching teams
- Professional Scrum Master II
- Advanced class for Scrum Masters
- Professional Agile Leadership
- For leaders and managers of Agile teams
- Professional Scrum Product Owner
- For Product Owners
- Professional Scrum Product Owner - Advanced
- Advanced class for Product Owners
- Professional Scrum with Kanban
- For anyone interested in learning about implementing Kanban principles within a Scrum Team
- Scaled Professional Scrum with Nexus
- For three or more teams working together on a single product
Both public and private classes are available. To learn more, contact Rebel Scrum.