4 Steps to Managing Scrum Meetings More Effectively
Four ways to help make your Scrum Meetings more effective (and, yes, more fun).
To many who are new to Scrum, the strangely named and the rigidly enforced “rituals” such as daily standups, sprint planning, and retrospectives can be perplexing at best and a distraction at worst. The short daily stand-ups aside, the longer meetings such as the sprint planning and retrospective meetings can turn into mentally and physically exhausting “free for all” debates without expert moderation and coaching of a seasoned and inspired Scrum Master.
This challenge — one of five that pose the biggest stumbling blocks to implementing Scrum effectively — is very often the main reason that Scrum adoption falters in many teams. Their enthusiasm for the process becomes worn down by the long debates, inconclusive discussions, and lack of meaningful commitment or action that results from these meetings. This can be especially difficult to address, especially since those very meetings are so integral to the practice of Scrum!
4 Steps to Managing Scrum Meetings More Effectively
1) Recognize that having these “rituals” is essential in the success of Scrum
There is a reason that the Scrum team should set aside 10% of their total sprint time on these meetings. They are not simple “overhead administrative” events. They are part of the work and work needs to get done in those meetings.
The reason these meetings are rigidly scheduled and enforced (both in terms of their regularity, their agenda and the attendees) is to provide the structure and rhythm for work to be done, and for important updates to be communicated within the team. Without such a structure, teams will not be able to self organize, as they will need a coordinator/taskmaster to make sure that everyone is moving along in the same direction. The meetings allow the entire team to participate in such informational exchange and subsequently to regulate and redirect itself.
2) Remember what the role of the Scrum Master is
The role of the Scrum Master in those meetings is not to be the team manager, but the team’s chief problem solver and information conduit, ensuring that everyone is on the same page and everyone’s impediments are surfaced and resolved as effectively as possible.
The meetings that tend to be the hardest to manage are the sprint planning meetings and the sprint retrospective meetings, because these meetings force the team to consider matters typically outside of its everyday work. For example, customer and business requirements, through the voice of the Product Owner (in the case of the sprint planning meeting), or process improvement and team development (in the case of the sprint retrospective). As such, these meetings, which encourage intense debate and disciplined, rational, and objective decision making, typically push the team outside of its comfort zone.
That’s where having a good Scrum Master to help guide the team can be crucial.
3) Keep Planning Simple
Some teams spend an inordinate amount of time (far more than stipulated) in sprint planning, as they rigorously debate prioritization of the sprint backlog, and then spend even more time estimating with excruciating details each and every of those backlog items. Granted that estimation is among the hardest thing to do well in Scrum, teams can forget that Scrum has defined many techniques to simplify the process (planning poker, t-shirt sizing, etc.). Not to mention you can only aspire to some level of certainty in planning and estimating — there will always be unknowns and unplanned items or underestimated work in a sprint. After all, the whole idea of Agile is to provide the structure and tools to deal with uncertainty, whether it is at the long term or short term.
4) Ruthlessly Prioritize
One typical reason that teams lose a lot of time in prioritizing is that they lose sight of the bigger picture of how the stories fit into the overall sprint, the next release, and the road map. Engineers love building things, and they will always be drawn to trying to build more and build now (rather than build less and build later). This can cause planning to be a painful, contentious exercise. Product owners need to be more proactive in grooming their backlog by ruthlessly prioritize features (as described by Vik Singh, the CEO of Infer, in a recent blog post), so that their teams do not get distracted by even the faintest whiff of a non-essential product feature or enhancement.
That is not to say that having fewer debates and rigorous discussions is necessarily a good thing. The sprint retrospective, in particular, can swing from being extremely contentious to being listless and dominated by apathy when team members fail to see their ideas for improvement implemented or taken seriously.
4 Bonus Scrum Meetings Best Practices We’ve Incorporated at OpenView
There is no magic formula nor a silver bullet that I can offer for this challenge, because the dynamics of these meetings really depend on the temperament and social interactions between individual team members, which vary dramatically from team to team. I can only offer some ideas that we have tried ourselves over the last seven years here at OpenView. We’ve struggled with the very same issue, and my guess is nearly every team has, on and off as scrum teams get formed, outgrow themselves, new team members and Scrum Masters join and leave the team, etc.
- We’ve spent more time grooming the backlog outside of the sprint planning meetings. We’ve given each product owner a regular time slot to work on the backlog of their projects. They also use that time to update their highest priorities, write more detailed user stories, and even get a team member or two to vet those stories before they surface at the sprint planning event.
- We’ve devised new metrics to enforce our focus factor. For example, we try to limit our teams to work on 2-3 concurrent sub projects at any given point, so that our planning and estimating work can be more limited and focused. This also helps with improving the quality of our estimation (as people have to switch gears from project to project less often), and simplifying the prioritization challenge.
- We’ve rotated the order of the projects to be discussed in the prioritization and estimation meetings, so that if there is a particularly contentious project, it does not dominate multiple consecutive meetings, and the team gets a break from dealing with such mentally taxing debate.
- We’ve started using the “Happiness” metric, among other things to kick off our sprint retrospective meetings, so that there is a fresh way to look at the team’s performance and ways to improve it. We also rotate the moderator of the sprint retrospective meeting, so that all team members can have an opportunity to voice their opinion and be a leading advocate of their improvement ideas.
There are also some simple but effective strategies for managing meetings in general that can be readily applied to your Scrum meetings. If you are interested, please take a look at some of our older posts on the this subject: 4 Questions to Ask Before Scheduling a Meeting, and 4 Other Questions to Ask Before Accepting an Invite.
If you find this topic interesting, please take a look at my other posts in this series on the hardest challenges for successful Scrum adoption:
- Introduction: The 5 Hardest Challenges of Implementing Scrum
- Challenge 1: Developing a truly empowered, self-organizing, and self-examining team
- Challenge 2: Embracing rapid iteration
- Challenge 3: Adopting prioritization by impact
- Challenge 4: Applying realistic but practical estimation
- Challenge 5: Managing Effective Scrum meetings
- BONUS: The Ultimate Guide to Retrospective Meetings
What steps have you taken to improve your own Scrum meetings? Please share your ideas in the comments below.
Photo by: Jukka Zitting
Achieving true product-led growth takes a winning combination of free parts of your product, virality, paying users, and more. Startups spend years (and thousands of dollars) trying to figure out the right model for viral growth – and many never do. So how do you succeed at PLG. Find out here.
Eraser founder, Shin Kim, shares why his company, Eraser, a whiteboard for engineering teams, built an AI sidecar that ultimately drove 30% of all product sign ups. Learn more here.
Miro’s Kate Syuma shares how the company’s growth team iterated smart to improve the user onboarding journey for their popular collaborative platform.