I really hear this a lot and I don’t want to sound pedantic, but I will start with my view: Scrum has zero meetings. Scrum has events. And no, this is not a play on words.
Repeating: Scrum has no meetings. Scrum has events. And each and every one of its five events has a clear purpose.
Historically meetings have agenda and in order for the meeting to run its course we need to go through the agenda items. Events in scrum have a clear goal, an outcome to be generated by the end of it but no specific format to run the session. Historically and practically, meetings can have, but do not enforce an objective. When people need to talk about something they send meeting invites. The meeting may or may not generate outcomes. It might not even be clear why people are in a meeting or if the correct audience is present.
For skilled facilitators used to schedule and run meetings with the proper quorum, asking for preparation, and starting with the goal in mind, yes, go ahead and think of the scrum events as meetings if you’d wish. Bear in mind that these “meetings” are recurrent. That is because of:
- simplicity: periodically, same time, same place. This reduces the complexity for those who book and makes it easy to remember for those who need to attend. And in the end, it becomes a habit, a groove.
- inspection and adaption: these events are signals, markers of specific points in the process that help us course-correct. They depend on each other to make the cycle through which we create and readjust work. That is Scrum.
Why the malaise with the “many” Scrum events
Now, despite the nomenclature and even if you are not convinced by my argument of before, Let’s take a look on possible reasons why people have the feeling these “meetings” are too many. I feel they are all beyond the nomenclature issue and more relate with the organizational aspects that Scrum unearths. What are those?
- Scrum asks for accountability. That means you cannot just show up to a “Scrum meeting” and be on your email or disengaged. They are moments for team synchronization and/or stakeholder interaction. You have to be present body and mind.
- Because of the nature of the “Scrum meetings”, a lot of transparency takes place: what is the plan, how it is progressing, are things working. In an environment of distrust and blaming culture, or just plain command and control, people working in Scrum might feel too exposed.
- Scrum requires collaboration. All these synchronization points require people to talk to each other, but more importantly, to own and deliver on shared goals and responsibilities. Some people are just not instantly open to it for numerous reasons.
- More “discussions” and “meetings” might pop-up. To be able to commit to a goal together, teams might discover they are actually not well equipped on skills or resources. Things that could be hidden before, now are in the open. Many organizations that think Scrum is “that framework Agile teams use” will be confronted with the fact that the whole organization has to change to adopt Scrum. People will need to talk. A lot more than before sometimes.
After this general view, let’s jump into each event and try and detect common misconceptions and traps to watch out for.
The Sprint Planning
The purpose of the sprint planning is to commit to the work for the next cycle, called a Sprint. Plain and simple. Scrum operates on a commitment basis, it is one of its fundamental values. A successful sprint planning has only one possible outcome: a commitment to a goal to be achieved by the end of the sprint. The result of the Sprint Planning is what gives focus to the Sprint.
A lot can be said about the format for the session and about what happens there. The maturity of the organization and level of autonomy of the teams will dictate the impact of the plan the team generates, but ultimately, a Scrum team is all accountable and able to do something. In the Sprint planning they talk about what is the most useful thing they can do this sprint, how they can do it. Can they formulate it as a goal? Can they lay out a plan?
Should you estimate during sprint planning? Is it OK to invite others to the planning? Do we break down the stories during planning or before? How long will that take? All of it is sorted out by a competent and willing Scrum Master or Agile Coach. These are important details that need to be tended to, but if we get stuck there we miss the point. If a team does not use User Stories, if the team does not estimate (with or without story points) if the team does not do a refinement prior to the session, but still sorted out a Sprint Goal that speaks to the product backlog and commit to achieve it with a clear plan on sight, the Sprint is planned and the team is running.
The Daily Scrum
The way I describe the daily Scrum to my teams is that it is the heartbeat of the Sprint. Would you want your heart to skip a beat? No!
What do we mean by heartbeat? Well, as a pulse-check, it gauges the health of the sprint. The objective of the Daily Scrum is to detect variation on the Sprint plan, aka to inspect progress, as early as the next day and to be able to re-plan if things are derailing. The Daily Scrum will give focus for the day ahead (or the next day depending on when you do it).
This is not the only time people come together to talk about problems, solutions, readjust. But with it in place we all get at least one clear time in the day to sync. It is also a lot less complex to have that session that we know happens with the full team, at the same time, at the same place.
The Sprint Review
The purpose of the Sprint Review is feedback and learning about the product and how it is made. Meeting in the end of every two weeks for 30 minutes to do a demo of something does not constitute a Sprint Review per se.
Should we demo? Should we show power point? How long should it be? Can people ask questions? Once again a competent and willing Scrum Master or Agile Coach can help. But at heart this event is an interactive session between makers (the Scrum team) and stakeholders (a client is just ONE of the stakeholders) to discover what was made possible in the sprint and assess the value of it in the context of the product and its backlog.
The Sprint Retrospective
Lack of participation, constantly missing team members tell the tale of a much misunderstood event. Can we skip it this sprint? Is 30 minutes enough? Give it some thought.
Quality, effectiveness, lessons learning. The purpose of the Sprint Retrospective is to get better as a team. Better as in more effective, better at collaborating, excelling on skills. It is a moment dedicated to learning and insights. It happens at the very end so that the team gets perspective. Happening in the end also means the rush of the Sprint is over for now. Heads are clear from the burden of delivery.
If you want more in-depth content on the Sprint retrospective, you can find it here.
Scrum – The process itself
Because Scrum in itself is not a meeting, we will not cover it in this post. But I will remind you that it is one of the events. It has a cadence, it has an intention. It is to close the outer loop of inspection and adaption.
Too many meetings?
So there you go, all the “meetings” you have in Scrum. Do you think they are many? You have:
- One “meeting” to decide what to do. As in commit to it!
- Everyday “meeting” among us to make sure we are on track.
- One “meeting” to show accountability or results and search for insights.
- One “meeting” to improve on quality and effectiveness.
Do you need more? Add what you need, and ask yourself: do they have to be “meetings”? Do they have to be recurrent?
If the above are too much, what would you remove without compromising transparency and effectiveness both for the team and for the stakeholders?
Interested in learning more about Scrum?
If you are interested in learning more about Scrum, check out my e-book. Scrum is very simple, and you can learn how to use it in a day. If you never worked with agile before it most certainly introduces you to agility in a very practical way.
