How to Utilize your Scrum Master Part 2: Master of Scrum Ceremonies
“ My Scrum Master scheduled all these meetings, but they are taking time away from my actual work!”
“Are they all really necessary?”
“Can’t we skip them if we’re busy?”
I’ve seen some people struggle with the amount of meetings that revolve around an Agile implementation, but these spaces where the team members come together are priceless. Scrum ceremonies are where the magic happens! Any good developer can write code, but when everyone works collaboratively and adds value to the team – this is where Scrum really shines.
If you ever feel that some of these meetings are ‘’just meetings’’ — your Scrum Master can help you understand their purpose. They all have proven benefits that can help the members come together, and really drive meaning to answer the question, “Why are we building this?”
These are the 5 main events an Agile team should hold regularly within an iteration. I’ll shine some light onto why these are done, as well as the role the Scrum Master plays, and where they can help if the event has lost it’s true north.
1. Daily standup
To help understand the daily standup, I like to bring it back to the basics, starting with its name: DAILY. STAND. UP. Let’s picture our team sitting together in the same office (even though this is becoming less of a norm). When it’s time for our daily standup, all members get up and huddle together in a room or in the hall to look at the Sprint board/backlog.
With one glance, everyone can see a high-level status of the team’s health. Then, every team member tells each other what they got done the previous day, and plan to get done that day. They shouldn’t give this status to the Scrum Master or Product Owner, but to the team. If the team holds the daily standup in a room, the Scrum Master’s place is at the back. The Scrum Master usually facilitates this meeting, but any other team member should also be able to do so.
Standups are susceptible to a number of problems. Is your Standup becoming a micromanaging session? Are you only checking tasks and focusing purely on time tracking? Is the standup used as a technical problem-solving session? If you notice any of these symptoms, ask your Scrum Master to intervene.
The standup must be kept simple: “Hey, everyone, I did this, and today I plan on finishing that. Oh, and I need help on this.” That’s it!
A good standup stays within 15 minutes, and it’s not the Scrum Master’s role to lead it. A healthy standup should start even if the Scrum Master doesn’t show up ( gasp! ). That’s right: the team should begin without being prompted and share their status for their peers to hear.
The Scrum Master’s main role in the standup? To check if the team needs help removing a blocker. After all, the standup is for the team, not the Scrum Master.
2. Retrospective
I hold the retrospective in the highest spot of importance for a team’s long-lasting health. I’ve seen the retrospective being ’skipped’ or canceled because the team needs that time for whatever reason, and I’ve seen team members struggle to stay engaged in these sessions.
Retros are where you grow. No retro? No learning, no adapting, no Scrum and no Agile – period. Retros are where the team recognizes what happened in the iteration and actually does something about it. Without the retrospective, an Agile team will just be spinning Sprint after Sprint and doing the same things over and over.
The foundations of Agile and Scrum are to inspect and adapt. If your retrospective sessions are just a space to ‘recap’ with no action, challenges, changes, questioning or healthy conflict, then you should ask your Scrum Master to bring in some evidence to strike up meaningful conversations.
Here are some good things a team can review in the retrospective with the help of a Scrum Master:
• Take a look at the Sprint burndown chart. Look for peaks or valleys and ask why that happened.
• Look at how tasking was done and if there were any team members who were burdened or idle. Some practices like swarming or limiting work in progress can be introduced.
• If there was an action item from the last retrospective, ask “Hey, remember that idea? How did that go?”
• If everything looks ‘ideal’ or ‘perfect,’ you can bring that up as well. Are there really no opportunities to improve? Is the team just trying to make the numbers look good when the practice may say otherwise?
It is imperative that the retrospective be protected and encouraged, and this happens when your Scrum Master makes it a safe space. What’s said in the retro stays in the retro. Your Scrum Master should keep people external to the team out of retros; it should feel like family dinner time. Sometimes it’s all good, sometimes it’s not, but it is a trusted environment where you tell your peers if there were good or bad practices. It’s open for feedback given by or to anyone. Mistakes are recognized, and we learn from them.
There are tons of different retrospective practices, techniques and even games that you can ask your Scrum Master to bring to the team.
3. Backlog refinement
This session needs a knowledgeable, engaged and servant-like Product Owner to make sure the team is 100% clear on the top priority items of the backlog. This is the right moment for the team to ask as many questions as possible to consider if a user story can be picked up for development. Any uncertainty or ambiguity needs to be addressed; otherwise, it may come up mid-Sprint when it can really hurt the team and the user/customer.
Although this session should be owned and facilitated by the Product Owner, the Scrum Master, as a relentless coach, should always be on the lookout for anything the team might be missing.
A crucial Scrum Master facilitation skill is scheduling “planning poker” after a user story has been presented and discussed. Your Scrum Master should be enabling a neutral story point estimation, ensuring that every voice is heard, and that no vote is influenced. If most of the voting is done by the same people, this needs to change. Everyone should vote at the same time, and every opinion matters.
This is a good space to ask your Scrum Master to refresh the team on their definition of “ready” and “done.” When a user story is deemed ready, everyone should have the same understanding on what this term entails.
4. Sprint planning
Sprint planning is just like a potluck party where everything comes together: lessons from the past Sprint, details from the refinement, a clean and prioritized backlog, the known velocity, and the team’s readiness to perform the next iteration with success.
The Scrum Master, while not directly responsible for coming up with all the food, is the key facilitator responsible for coaching everyone on what they need to bring to the party. If something was left behind in one of the previously mentioned ceremonies, some things will be missing in Sprint planning.
Before Sprint planning happens, your Scrum Master should have the space prepared to maximize the value of this session. A simple step-by-step guide for this event would be:
• Look at the top backlog stories (which have been refined, sized and deemed ready for development)
• The team ‘pulls’ them into the Sprint plan
• The Scrum Master coaches the team on how much to take based on known velocity
• The team commits
• The Sprint can begin
Note that it is not the role of the Scrum Master to ever decide which stories the team should include. As a coach, your Scrum Master can (and should) give the team advice. Maybe there is a story that has been recently talked about by the stakeholders; should we think about that one? Maybe the team mentioned a big dependency for a story, but it doesn’t seem that it’s been resolved; should the team really take that on? While it will always be up to the team to make the final decision, these sorts of questions can guide them in managing their commitment.
Your Scrum Master should keep the team’s velocity sharp, as well as bring any topics from the retrospective that might affect the new Sprint. The team needs to focus on the Sprint goal; your Scrum Master should keep an eye on everything else.
5. Sprint review
The Sprint review is where the Sprint backlog is finally transformed from user stories into value. Finally, the code is working and it is showcased as something the users can look at! Your Scrum Master needs to make sure that this session happens every Sprint, regardless of the stories, commitment, and blockers, or if stories had to be split. This is our ‘show and tell,’ and even stories that were not finished have a story to tell. Although they are not ‘demoed,’ it is important to bring them into the context of our team.
The development team performs the demo, and sometimes the Product Owner can lead the showcase. It is always an informal meeting because it should be a familiar collaboration between the team and the team’s stakeholders.
The Sprint review should never be a session to show the PO what was done. When the review happens, the PO should already know what’s going to be presented, and only ‘done’ stories make it into the demonstration.
Your Scrum Master can help keep attendees aware of the purpose of the meeting. Sometimes people get excited, and they want to see more: “Can you click there? Let’s see something else. Ohhh what does that button do?’’ Your Scrum Master can remind everyone that we are going to see what was done within the Sprint, and feedback based on the demo is appreciated and encouraged. If there are other ideas about features or changes, the Product Owner can manage them.
There are additional events your Scrum Master might attend. If you are on a Scaled Agile® implementation, there will be opportunities for cross-team coordination. Sometimes, if teams are distributed across different time zones, your Scrum Master will find a balance in everyone’s calendar to maximize collaboration.
My advice to any Scrum team member is: if you’re not sure about an event’s purpose, or if you feel it’s not being productive, please bring it up with your Scrum Master. This type of feedback is crucial to becoming a high-performing team. I assure you that every Scrum ceremony has its purpose, even if sometimes that purpose needs to be re-visited. Your Scrum Master is there to help!
