Myth: The Scrum Master has to be at every meeting

Being a great Scrum Master is all about balance. The Scrum Master coaches the team in self-management, but they are also responsible for helping the team focus on value by improving the adoption of the Scrum framework and removing organizational impediments. They ensure that the Scrum events are positive, productive and kept within the time box, but they don't have to attend every meeting.

Take, for example, the Daily Scrum.

The Daily Scrum is a 15-minute time-boxed event for the Developments to inspect progress toward the Sprint Goal and to review and update their plan for the upcoming workday. This is their chance to see how the Sprint is going and collaborate around anything that may be holding them back from delivering a done increment by the end of the Sprint. According to the Scrum Guide, the Scrum Master ensures that the event takes place and that the Developments keep it short and use it effectively. But the Scrum Master doesn't have to attend every last Daily Scrum event.

For new Scrum teams, of course, the Scrum Master is usually facilitating the Daily Scrum every day. We help them try different ways of organizing the conversation, such as asking the three questions round robin for each developer—"What did you do yesterday? What will you do today? And do you have any blockers?"—or we sometimes facilitate the conversation by walking the board (going through each Product Backlog item assigned to the Sprint and talking about the status of each).

But after a while, sometimes as a Scrum Master, I will skip the Daily Scrum periodically and ask one of the Developers to lead. My purpose here is to get the team to step forward and lead the event themselves. After a while, depending on the Scrum team's needs, I might not go at all, but I just check in by asking the developers how it's going and if they are collaborating, and I might attend once in awhile, just to make sure that collaboration is going well. For other teams I may always facilitate just as a way of helping out. It depends on many factors, including how many other teams I am supporting as a Scrum Master. But it's better if it really is the Developers' meeting, and they are deciding how to approach the conversation.

At other Scrum events, the whole team's attendance - including the Scrum Master - is required. But that doesn't mean that the Scrum Master must lead everything. For Sprint Planning, it may be a team effort where some parts of the discussion are lead by the Product Owner and some by the Scrum Master. At the Sprint Review, the Product Owner often kicks that event off.

The Sprint Retrospective is a particularly interesting case. The Retrospective is arguably the Scrum Master's most important event. Its purpose - helping the team improve how they work together, update their processes, and their Definition of Done - aligns perfectly with the Scrum Master's accountability to improve the adoption of Scrum. And still, while I am often leading it as a Scrum Master, it can be very effective if someone else leads the Retrospective sometimes. For example, about once a year at a previous team, the Product Owner would lead this event. Sometimes I would ask a Developer to lead, and several memorable occasions, I invited the IT director to lead the conversation (with the team's permission) because we were having trouble with environments and the team wanted to brainstorm with her directly about how to address this. Be creative.

What about Backlog Refinement, problem-solving sessions, and stakeholder touch-base meetings? As a Scrum Master, I actively help the team determine the most effective way to handle refinement—whether that’s a dedicated weekly session, smaller focused groups working ahead of time, or a combination of both. Once the approach is decided, I ensure the sessions are productive, that the right people are involved, and that there is clear ownership. However, I don’t attend every refinement or stakeholder meeting.

For urgent problem-solving or impediment-removal discussions, I work closely with the Developers to get the right people in the room quickly and I frequently facilitate those conversations—but not always. My role is to support progress and remove obstacles without stepping on the team’s autonomy. The key is staying on top of impediments while giving the team space to own the solution.

As the Scrum Master, remember that you are responsible for ensuring that the events take place and that they are positive, productive, and kept within the time box - but you do not lead every last meeting. It would be less productive if you did, because having someone else lead an event lets the team look at a problem from a different angle, and that is always a good thing that unlocks the creativity of the team.

Why This Balance Matters

A great Scrum Master coaches the team toward self-management while still serving as the champion of the Scrum framework and promoting focus on value delivery. Leading every meeting risks turning the Scrum Master an administrator, but you can't just let them run amok either. I once worked with a Scrum Master who wouldn't facilitate anything because she claimed that the team was "self-managing". So meetings were all over the place and they were like a ship without a rudder. The team was frustrated - and annoyed - because no one was wrangling the conversation. Talk about not a positive, productive or time boxed experience! Most of their meetings went long for this reason. There has to be a balance. Sure, you coach them in self-management because otherwise you are a crutch. But that doesn't mean you can walk away from your responsibilities either.

Practical Tips for Scrum Masters

• Start with observation and facilitation: Attend and guide initially to model good practices, then gradually step back from some of the Daily Scrums to see if they go better without you. If not, come back and re-evaluate.

• Set clear expectations: Ensure everyone understands the purpose of each event so the team can self-correct.

• Use retrospectives: Regularly discuss team effectiveness—what's working, what's not, and how the team can improve. And for this event you do need to make sure that the team knows in advance who is facilitating the Retrospective each Sprint. And remember, even though you are required to attend Sprint Planning, Sprint Review and the Retrospective, you can plan in advance who will facilitate each one so that fresh voices are heard.

Being a great Scrum Master is about balance. It's not about being omnipresent - it's about being strategically supportive so the team can thrive without you hovering. When the team runs smoothly on its own, you've succeeded in your core accountability: improving the effectiveness of the Scrum Team.