Our previous article in our Perfect Planning series was dedicated to the Product Owner’s To Do list. If you take a look at the ScrumOne process, you’ll see that the Scrum Master’s To Do list is the longest, so let’s take it gradually. The first half of the list includes:
- Check Product Backlog readiness before the event.
- Ensure that the event takes place.
- Ensure that attendees understand the purpose of the event.
- Capture availability and capacity information for the Sprint from the Scrum Team.
- Cooperate with the Product Owner and Developers on User Stories clarification.
Check Product Backlog readiness before the event.
The Scrum Master has to have an overview of the state of the Product Backlog. If there are no priorities set, or there are not enough User Stories Ready to be pulled into the Sprint, they need to actively help the Product Owner put the Backlog in shape well in advance of the Planning session. A Product Backlog that is not clear and ready before the Planning session leads to long Planning and many ambiguities. The team gets tired and loses focus. That is something we want to avoid, don’t we?
Ensure that the event takes place.
The Planning event must take place. There is no way that Planning can be left out, no matter how it turns out and in what state the Product Backlog is in. There are multiple Planning modes to take into account the different states of readiness of the Product Backlog, so Planning can always take place. (More about the Planning modes in upcoming articles.)
Ensure that attendees understand the purpose of the event.
There are several ways to ensure that everyone understands why we need the Planning event. One is to explain to the Scrum Team the purpose of the meeting and what the Agenda is; another is to let the attendees read the ScrumOne process and confirm they correctly understood the purpose of the event.
If the attendees of the meeting do not understand the purpose of the event, it is much more difficult for the Scrum Master to facilitate it. The event can be disorganized and non-productive and can easily consume all of the allotted time and still not fulfill its purpose.
Capture availability and capacity information for the Sprint from the Scrum Team.
Developers need to realize how much work they can take into the Sprint based on how much time they have. And not only for themselves, but for the whole team. If someone takes the same amount of work even when they are on vacation for half of the Sprint, the Scrum Master has to step in.
It is best to do it in a visual way on a screen or whiteboard. It is quite hard to really realize how much space for work you will have in the Sprint if you just talk about it. A clear image depicting the days available goes a long way in this case.
Cooperate with the Product Owner and Developers on User Stories clarification.
The Scrum Master acts as a discussion facilitator. If the discussion about the item is sluggish, the Scrum Master must stimulate the debate and make sure that everyone understands the item and knows what is expected of them.
It is not always easy to identify the right time to step in, but remember that it is better to ask than be silent and lose the information. If you ask questions, you never know if you inspire somebody by that question and they realize something. You may ask a hundred times and be monotonous, but you could ask the hundred-and-first time and inspire. Isn’t it worth it?
This was the first part of the Scrum Master’s To Do list. The remaining points will be explained by my colleague next time.