A Scrum Master is often described as the person who looks after a Scrum Team, and the 2020 Scrum Guide draws the accountability wider than that. Two accountabilities sit with the role. The first is establishing Scrum as defined in the Scrum Guide, which is done by helping everyone understand Scrum theory and practice, both inside the Scrum Team and in the organisation around it. The second is the Scrum Team's effectiveness.
Effectiveness here means how well the team works. A team that ships steadily while nobody will raise a problem in the Sprint Retrospective is producing without being effective, so the Scrum Master still has work to do in a Sprint whose Increments all arrived on time. The Guide calls the Scrum Master a true leader who serves the Scrum Team and the wider organisation, and it sets that service out in three directions.
Serving the Scrum Team
The Guide lists four services to the team.
- Coaching the team in self-management and cross-functionality.
- Helping it focus on creating high value Increments that meet the Definition of Done.
- Causing the removal of impediments to progress.
- Ensuring all Scrum events take place, are positive and productive, and stay within their timebox.
The fourth service is the one that gets stretched furthest in practice. Ensuring that an event takes place and stays inside its timebox is a smaller job than chairing it, so a Scrum Master who opens every Daily Scrum and works down a list of names has taken the event over. The Daily Scrum belongs to the Developers, who choose how to run it and may ask the Scrum Master to be its facilitator.
Serving the Product Owner
Service to the Product Owner takes the same shape, and the Guide again lists four.
- Helping find techniques for effective Product Goal definition and Product Backlog management.
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.
- Helping establish empirical product planning for a complex environment.
- Facilitating stakeholder collaboration as requested or needed.
Stakeholder collaboration carries a condition the other three do not. The Scrum Master helps with it as requested or needed, so a Scrum Master who convenes the stakeholders of a payments platform without being asked has made a decision that belongs to the Product Owner.
Serving the organisation
The third direction reaches past the team, and the Guide lists four services here too.
- 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 for complex work.
- Removing barriers between stakeholders and Scrum Teams.
This is the direction most often left out, because it needs standing that the team cannot grant. A Scrum Master with no remit outside the team keeps to the part of the work that is visible inside it, which is how the accountability shrinks into maintaining a board. Most of what slows a team starts somewhere else, in funding cycles that assume fixed scope and in approval gates nobody owns, so a Scrum Master who never leaves the team room cannot reach the cause.
Causing the removal of impediments
The Guide's verb here repays a careful reading, because it says the Scrum Master causes the removal of impediments. Causing a removal and performing one are different acts, and the difference is practical. An impediment the team can clear for itself should be cleared by the team, because a Scrum Master who clears every obstacle teaches the team to escalate, and escalation is the habit self-management exists to replace.
What the Scrum Master owns is the result, so an impediment that survives Sprint after Sprint is theirs to answer for, whoever would have to act on it. That might mean making it visible to a manager who can act, changing the policy that keeps producing it, or saying in the Sprint Retrospective that the same blocker has now outlasted three Sprints. It also calls for judgement about what counts as an impediment. A test suite that fails at random and costs the team a day a week is one. A ticketing tool nobody likes is a preference, and a Scrum Master who spends their standing on preferences has less of it left when a real impediment appears.
The limits of the Scrum Master accountability
The Scrum Master is not a project manager, and the reason is structural. There is no plan to own, no schedule to defend and no scope to hold the team to, because the Product Owner decides what gets built and the Developers decide how much of it they take into a Sprint. When a Scrum Master reports progress against a plan of their own, that plan takes back the decisions Scrum distributed.
Two smaller misreadings follow the same pattern, since the role is neither administrative nor directive. Booking a room and writing up a Sprint Retrospective are things a Scrum Master may do to help, and neither of them is the accountability. Assigning work sits further outside it again, because the Developers decide who does what, and a Scrum Master handing out tasks has rebuilt the status meeting the Daily Scrum exists to replace.
The verbs the Guide uses for the Scrum Master
Those limits are all visible in the verbs the Guide chose. All twelve services share one grammatical feature. Coaching, helping, causing, ensuring and advising each describe somebody who makes an outcome possible, and none of them describes the person who produces it. Most scenario questions on this subject turn on that distinction, so an answer in which the Scrum Master directs, assigns or decides for another accountability sits outside the role.