Questions like the following are coming up quite often when I do Scrum training:

Why should the Scrum Master and Project Manager roles be filled different people? (Quora)

Will a scrum master for a team of 10 be a full time position or can a programmer fill this position if highly trained in agile planning? (Quora)

The theory behind those questions is that the Scrum Master is not a full time job. Those questions askers speculate you’re saving money by combining two roles or putting the responsibilities of the two roles on a single person.
Scrum master newcomers, product owners, team members, executives, all sorts of stakeholders ask these questions. Everyone seems to immediately understand from the three roles in Scrum that being a team member is a full-time job – because it develops software all day long – and that being a product owner is a full-time job – because it develops the product all day long – but it seems far beyond imagination what the job of a Scrum master might be and why the heck would be a full-time job too.

Perhaps those who inquire don’t know what a Scrum Master does all day?

Here’s a list of 42 things that I would say are part of a Scrum Master’s job:

Learning

• Continuing learning regarding everything Agile (e.g. visit user groups, attend conferences, read books, write blogs, etc.).
• Consulting team members regarding everything Agile.
• Helping the team to create information radiators.
• Giving feedback to the team.
• Encouraging the use of Agile Engineering Practices within the development team (this is a huge field to spent a Scrum Master’s time in, including e.g. one click releases, continuous delivery, feature flags, and many more).
• Challenge team with Agile management innovations (e.g. FedEx-Days).
• Exchanging constantly with other Scrum masters in the organisation (e.g. through community of practice).
• Doing Gemba Walks.

Meetings

• Facilitating meetings for the team. This includes:
  • preparing
  • moderation
  • postprocessing
• Holding retrospectives. Retrospectives are special meetings, therefore I count them separately.

Team Dynamics

• Coaching team members (e.g. with one-on-one coachings).
• Mediating through conflicts.
• Helping the team to make decisions.
• Fostering the developer team’s self-organisation.
• Mediating the general conflict of goals between development team (high technical quality) and product owner (more features).

Product

• Helping to write or split user stories.
• Helping to write or adapt product visions.
• Helping to order product backlog items.
• Helping with the release planning.
• Being familiar with the team’s work (i.e. the product).

Big Picture

• Bringing people together who should talk to each other.
• Keeping in touch with every stakeholder regularly.
• Helping the team to report to management.
• Helping to further the Agile community within the organisation.
• Organizing exchange events like Open Spaces or World Cafés for the team, its stakeholders, and its organisation.
• Sharing insights throughout the company (micro-blogging, blogging, internal conferences, etc.).
• Being a contact person for everyone in the team and their stakeholders regarding Agile.
• Giving learning opportunities to people in the organization (e.g. talks or workshops) and letting them learn important Agile concepts like e.g. technical debt.

Change

• Helping the team to get rid of impediments.
• Suggesting new metrics for the team as catalysts for change.

Mirror

• Reflecting Agile and Scrum values to the team.
• Reminding the team of their arrangements (e.g. policies).
• Helping the team to continuously improve their process.
• Reflecting issues to the team through observation from outside of the team.
• Asking open questions.
• Checking all the models the team uses (e.g. Sprint backlog, metrics, etc.) and show them differences between the model and the real world.

Miscellaneous

• Helping the team to keep focus (e.g. by acting as a buffer between external distractions and the team).
• Helping the team to maintain their Scrum tools (Story board, Action board, charts, backlogs, etc.).
• Helping team and product owner to find a suitable
  • definition of done
  • definition of ready.