One of the first things that I usually hear after describing the Scrum framework and its five events to someone new to Scrum is, “that’s a lot of meetings!”
I get it — at first glance, it seems like a lot. But it really isn't when I get the person to take a closer look. I explain that if they listed all of the meetings they have in one month, it would probably seem like a lot too. (And, the number might be a surprise).
Examining the five events, the first thing to point out is that the Sprint is not a meeting; it’s a container for all the other events. The Sprint Planning meeting happens just once per Sprint, and the same goes for the Review and Retrospective events. Only the Daily Scrum happens every day, and that event has a 15-minute timebox.
Following is a description of each event and how you can reduce the need for other meetings by practicing them.
The Sprint
The first event in Scrum is the Sprint. As mentioned, it isn’t a meeting but rather a container for the other events. I think of the Sprint as the heartbeat of Scrum because it sets the cadence and frequency for the other events. The Sprint starts with the Sprint Planning and ends with the Sprint Retrospective.
The Sprint has a timebox of no longer than one month. The team can choose the Sprint duration that works best for them. Many teams select a one- or two-week time period. What’s the best length for a Sprint? As with many things in Scrum, it depends. The duration should be long enough to enable the Scrum Team to deliver a Done increment of usable product, with a preference towards a shorter timescale. In high-risk environments (say with unknown technology needs or rapidly changing customer requirements) it’s better to select a shorter Sprint. This limits the time investment before getting back together with the customer and other team members to evaluate what got completed and decide what to do next.
How the Sprint reduces the need for other meetings
It’s difficult to make detailed plans with any certainty beyond about thirty days. Planning for longer than one month takes more time and comes with more risk.
This doesn’t mean that the Scrum Team does not look beyond a one-month horizon. They can create a forecast that projects what the Scrum Team might be able to deliver over a more extended period. But, it is only a forecast based on the team’s current work rate and what is in their Product Backlog. In Scrum, the Product Backlog itself is the plan.
Sprint Planning
The second Scrum event is Sprint Planning, where the team plans the work of the Sprint. Sprint Planning includes selecting what Product Backlog items (PBIs) to deliver and creating a plan for how to complete the work. The team also identifies a Sprint Goal, which provides focus by describing the why behind what they are delivering this Sprint.
How the Sprint Planning event reduces the need for other meetings
By planning the Sprint together, the team can brainstorm the what, when, and how of delivery, reducing meetings because:
The team doesn’t need to meet several separate times to plan each feature.
The team understands what each team member is doing during the Sprint, making it easier for the team to adjust if they need to make a change.
The team does not have to plan in great detail what they will complete every day of the Sprint. Instead, they plan just enough to get started, and the rest of the plan emerges as they learn more.
Daily Scrum
The Daily Scrum is a 15-minute meeting for the Developers, which allows them to monitor their Sprint Backlog progress and create their plan for the next 24 hours. This event aims to increase the likelihood of delivering a Done increment of product that meets the Sprint Goal.
How the Daily Scrum reduces the need for other meetings
At the Daily Scrum, the developers meet to see how they are progressing towards the Sprint Goal and to adjust their plan as needed. “Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.” - 2020 Scrum Guide.
I cannot tell you how many times a developer has struggled in silence for days with a problem they didn’t know how to solve when working on a waterfall project. With Scrum, that can never happen. Team members identify such issues daily before they become a big problem for the Scrum Team. The entire team is accountable for delivering the Sprint backlog, so if one person is struggling, the other members help.
Sprint Review
During the Sprint Review, the Scrum Team meets with stakeholders to discuss what they completed during the Sprint. They inspect the Sprint outcome and collaborate on what to do next. It’s a critical opportunity to hear directly from stakeholders about what the team delivered. Scrum Team members also get to see the entire increment.
How the Sprint Review event reduces the need for other meetings
By meeting with them frequently, the team can hear how stakeholders regard their work and use this information to brainstorm ways to maximize the value they deliver going forward. Teams can adjust their course as needed and avoid heading in the “wrong” direction for more than one Sprint. This early feedback eliminates emergency meetings down the line when the team at long last finds out what they delivered is not what the stakeholders expected; instead, they find out this information early and act upon it as soon as possible.
Sprint Retrospective
The final event in the Sprint is the Sprint Retrospective. This event is an opportunity for the team to inspect themselves. Members discuss how the Sprint went regarding individuals, interactions, processes, tools, and their Definition of Done.
As an outcome, the team identifies ideas for improvement and implements them as soon as possible. Many teams decide to place improvement ideas into the next Sprint Backlog to add transparency and make work item completion more likely.
How the Sprint Retrospective event reduces the need for other meetings
The Sprint Retrospective is an opportunity to discuss anything that went wrong in the Sprint and brainstorm ways to address it. This discussion happens every Sprint, so problems do not fester and worsen over time.
Additionally, this event allows the team to brainstorm ways to improve their processes and interactions, often eliminating meetings about conflicts and inefficiencies.
Conclusion
The five Scrum events provide just enough structure and coordination to allow the Scrum Team to deliver value. These events are deliberately short so that Scrum Team members cannot go down a rabbit hole with endless non-value-added discussions. Try it and see how much time your team can save with less meeting time.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
Introductory class for those new to Scrum
Geared towards Scrum Masters coaching teams
Advanced class for Scrum Masters
For leaders and managers of Agile teams
Professional Scrum Product Owner
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.
Comments