What do Scrum Masters do all day?

Question

So this is a question that many people have answered on their blogs and I think one person even wrote a mini book a answering this question. However, I wasn't able to relate to them so I am hoping to get some input from experienced Scrum Masters / Coaches over here.

Let me elaborate with some scenarios:

• You are a SM, you saw the daily scrum take place smoothly, the team is gone back to their desks to work.
• You are a SM, you have worked with the PO and the team and the Product Backlog is appropriately groomed for the upcoming Sprint, due in say 2 weeks.
• The organization is doing quite well in their agile journey and doesn't necessarily need any urgent coaching
• All the artefacts are up to date thanks to an online tool that automates quite a bit

Also, you can assume the team is in the "Performing" stage of team development and you are a full time employee for this one team.

So how do you fill the rest of your day/s?

I am not look for answers listing responsibilities of a SM, like removing impediments or coaching. Neither do I want a daily schedule with entries like "meet with John to discuss XYZ". That doesn't take much time.

Instead, I am hoping to get some real-life examples that can be replicated. Something that is actually common for all SM of software teams.

For example, in my own case, I have mostly worked on mega projects so the backlog grooming took forever in the early stages of the project and as things progressed, I would help out with end user support, training, pick up some independent technical tasks and get them done, or just do documentation. These would take from a day to a whole sprint, especially if I pick up a couple of stories.

What about you guys? I am particularly keen to get some feedback from purists who say 1 SM, and only 1 SM, per 1 or 2 teams at most.

Answer 1

Personally I've taken on extra responsibilities that don't necessarily sit with a team, e.g. like managing the companies Software Licences .

Generally helping out in the smooth running of the office, helping management with non development related tasks. Researching new Agile topics.

Additionally linking in with other scrum masters to ensure the scrum experience is as closely aligned as possible across the company.

But hey ... that's just me

Answer 2

I've worked as a project manager for 15 years and have been working as a scrum master part-time (of the 15 years of PM work) for 3 years and full-time as a scrum master for 3 years. Here is what I typically do, but in the end my job is to help teams be as productive, effective and efficient as possible to deliver the highest business value as they possibly can in each release:

1. Facilitate retrospectives, sprint and release planning sessions. This involves all the up front planning needed to make the meetings effective. For retros, I will look at how the team has been doing and choose a retro plan that is a good match for the team's needs at the time. For planning, I'll be reviewing all of the metrics I've been capturing for the sprint or the release (sprint and release velocities, throughput, cycle times of story and feature completion, and WIP). I try not to run daily standups (aka daily scrums). I let the team do that, as it is their meeting. I will intervene only when I need to.

2. Track story and feature metrics. I use this to track the performance of the team. I use velocity, cycle time, WIP, throughput, and Cumulative Flow Diagrams. I will use this information to provide to the team before all retros so we have facts to back up our conversation instead of guesswork.

3. I am a scrum master for two teams, so my time is broken up between the two. Still, I do have some downtime in between. So, what else do I do?

4. I have 1-on-1's with team members (usually a few times during the sprint) to see how things are going for them and what I can do to help them as a team member and in their professional growth. I'll work with their functional manager to support the team members achieve their goals by trying to get them exposed to new modules of the application or manage team capacity to get them training where needed.

5. I work on side projects like process improvement initiatives. I've worked with QA groups to help build a QA Community of Practice for instance. I have mentored and coached other scrum masters and Product Owners. I also usually facilitate release retrospectives, which requires weeks of preparation and collaboration with other scrum masters and management to make sure it is a good use of everyone's time. I will then follow up with any action items that come out of it.

6. I work with scrum masters from other products to share ideas and collaborate on new tools, techniques and such.

7. I do training sessions with teams on how to conduct presentations (internal / external), and teach them about different agile topics (scrum, lean, kanban, navigating conflict, etc.).

Answer 3

Learn. Read blogs, books, scientific articles or whatever you like to do to learn. Or code in new languages. Whatever you can think of that the team might benefit from later on. One of the most important things the SM does is learning. About the team, about the organisation and always be on the lookout for new things to try out. If you're really bored you can always find some other bored Scrum Masters and try out a workshop or just talk over coffee if they have some ideas on what to do.

Answer 4

In my experience... it depends. It depends on what stage the team is in, usually brand new teams need a lot of coaching because they usually have very little knowledge or don't know why some things happen. (one dev found it tedious to have 15 minutes "status update sessions" in his prior projects).

A lot of my to-do's usually come retro items the team proposes. This is because I've had to work with large organizations where there are dependencies on various teams.

Also, not related to agile at all but it's been a common experience that I've been the point of contact with a stakeholder or client when they want detailed reports or want a representative from the team in a meeting. I'd happily attend as long as they don't pull anyone from the team because there is a risk of getting pulled into too many meetings which I avoid for any member of the team.