The Scrum Master role: what they do on a normal Tuesday

The job title sounds like a manager's, and the role is nothing like one. A Scrum Master cannot tell anyone what to build, cannot assign the work and cannot approve it. Yet when the role is done well, the team runs better, and when it is done badly the damage shows within weeks. Understanding why is most of understanding the role.

What the Scrum Guide holds them accountable for

The Guide gives the Scrum Master two accountabilities. The first is establishing Scrum as defined in the Scrum Guide, by helping everyone understand Scrum theory and practice, inside the team and in the organisation. The second is the Scrum Team's effectiveness, which they pursue by enabling the team to improve its practices within the Scrum framework.

The Guide's one-line description is worth keeping in mind: Scrum Masters are true leaders who serve the Scrum Team and the larger organisation. The word that carries weight is serve. They lead by making others more effective, not by directing them.

Who they serve

The Guide describes three groups, and the work looks different for each.

The team

• Coaching the members in self-management and cross-functionality.
• Helping the team focus on creating high-value Increments that meet the Definition of Done.
• Causing the removal of impediments to the team's progress.
• Ensuring all Scrum events take place and are positive, productive and kept within the timebox.

The phrase "causing the removal" is deliberate. The Scrum Master does not necessarily remove an obstacle personally. Often the best response is to make sure the right person knows about it, or to help the team see that it can solve it itself.

The Product Owner

• Helping find techniques for effective Product Goal definition and Product Backlog management.
• Helping the team understand why clear and concise Product Backlog items matter.
• Helping establish empirical product planning for a complex environment.
• Facilitating stakeholder collaboration as requested or needed.

The organisation

• Leading, training and coaching the organisation in its Scrum adoption.
• Planning and advising Scrum implementations.
• Helping employees and stakeholders understand and enact an empirical approach to complex work.
• Removing barriers between stakeholders and Scrum Teams.

This third group is the one most often neglected. A Scrum Master who spends all their time inside the team, while the organisation keeps interrupting it with ad hoc requests, is treating the symptoms.

What it looks like in a week

Here is an illustrative week, not a prescription.

Monday. Sprint Planning. The Scrum Master is not running the meeting for the team, but making sure it happens and fits its timebox. They notice that the Developers are selecting more items than the last three Sprints suggest is realistic, and ask what is different this time. They do not answer for the team.

Tuesday. The Daily Scrum. They listen more than they speak. A Developer mentions being stuck waiting for access to a test environment. That is an impediment, and the Scrum Master takes it away to chase, after the meeting, with the person who can grant it.

Wednesday. A stakeholder messages a Developer directly with a new request. The Scrum Master has a short, friendly word with the stakeholder about routing it through the Product Owner, and a second word with the Developer about what to say next time.

Thursday. A one-to-one coaching conversation with the Product Owner, who is finding it hard to say no to a senior colleague. They practise how to explain the order of the backlog without apologising for it.

Friday. The Sprint Review and the Retrospective. The Scrum Master keeps both inside the timebox. In the Retrospective they notice that the same complaint appears for the third Sprint running, and ask whether the improvement agreed last time ever happened.

Nothing on that list is a status report or a ticket update. It is mostly observation, conversation and small interventions, which is why it can be hard to see from the outside.

What the Scrum Master does not do

• Assign tasks. The Guide says the Scrum Team decides internally who does what, when and how.
• Own the schedule or the budget. Those are not Scrum accountabilities. See the Scrum Master and the project manager for the contrast.
• Decide what to build. That is the Product Owner's call.
• Act as the team's secretary. Taking minutes and updating a tracker for the Developers undermines their self-management. The Sprint Backlog is a plan by and for the Developers.
• Fix every problem alone. A team that learns to expect the Scrum Master to solve its problems has not become self-managing.

The Daily Scrum is a good test. The Guide describes it as an event for the Developers. A Scrum Master who runs it, asks each person for a report and writes down the answers has turned it into a status meeting.

How effectiveness shows

The Guide makes the Scrum Master accountable for the team's effectiveness, which raises the fair question of how anyone would know. There is no single number, and the Guide offers none. The useful signs are visible in the team's own events: impediments that used to linger get cleared faster, the Retrospective produces changes that are carried out, stakeholders bring requests to the Product Owner and not to individual Developers, and the Developers run their own Daily Scrum without being prompted. When the team needs the Scrum Master less for the routine parts of Scrum, that is a sign the role is working, and the time freed goes to the organisation-level work the Guide also assigns to it.

Starting points for the first month

If you have just become a Scrum Master, a few habits are worth building early.

• Watch before you change. For the first Sprint, observe how the events actually run. You will learn more than from any questionnaire.
• Ask questions in preference to giving answers. "What would you like to do about it?" is often more useful than a suggestion, and it builds the habit of ownership.
• Make the impediments visible. A short list that everyone can see, with a name beside each item and a date, does more than a private promise to follow up.
• Protect the retrospective. It is the team's best chance to improve, and the first event to be dropped when a deadline is close.
• Know what you are accountable for. Establishing Scrum and improving effectiveness are measured by whether the team gets better, not by how many meetings you ran.

The Agile Manifesto principle that the team should reflect regularly on how to become more effective, and then tune and adjust its behaviour accordingly, is the one a Scrum Master serves most directly.

How to practise it

The role is easiest to learn by making the calls: which impediment to clear first, what to do with a late request, how to handle a standup that has become a report. In the simulator you can take the Scrum Master role through all five phases, with a Sponsor who wants more than the team can deliver. For situations to rehearse before then, see Scrum Master practice.