What do Scrum Masters do all day?

That’s a very popular question, and I’d like to give you a sneak peek.

I’ve already done a few videos on this topic, but I never did a full overview.

Ok, I made lots of videos about this topic, like “What do Scrum Masters do all day?” and a short 1 minute video showing a couple of hours in the morning.

This time I want to give you an extended version.

And actually, instead of showing you just one day, I’d like to cover a week, or even a Sprint.

Firstly, it will allow me to talk about the Scrum Master accountabilities during various meetings,

Secondly, some days are less active than others, that’s normal.

I want to give you as much insight into the work as I can.

So let’s get started. Watch today’s video to find out what would be on the to do list for a Scrum Masters (or keep reading).

But before I continue into the rest of the video, a quick reminder to subscribe to this YT channel, to like and to comment down below!

Now. I want to start by dispeling a common myth that we are taught in the corporate world.

The myth says that the busier your are during the day, the more valuable you are as an employee.

As I said – this is a myth.

People boast about how filled their calendars are and that they are tripple-booked every hour.

They also like to share how many emails they get every day – the more emails you receive, the better!

So when someone has a free schedule, the immediate thought is – well, they have nothing to do then.

WRONG!

The role of the Scrum Master is all about people and continuous improvement.

If we are busy in meetings and replying to emails all the time, we won’t have time to actually do our job.

A lot of the examples I will give you in this video will show the spontaneity of our work.

Everything I tell you in this video is true – real-life experiences from my Scrum Master journey. Not only that, but I also share what I actually did in those situations. Maybe not everything worked, but each story was a learning opportunity for me.

In this Scrum Master week, we’ll be looking at a team that was working together for 7 Sprints already. They have good team dynamics, but are still new to Scrum. Their Sprints run from Wednesday morning to Tuesday afternoon 2 weeks later. And we are catching them on the week where their 7th Sprint ends and 8th is starting.

MONDAY

It’s Monday morning. It’s a regular day, the 7th Sprint is ending tomorrow, on Tuesday.

The team will be focusing on finishing up the work and getting ready for the Sprint Review.

First things first, let’s check how the team is doing – I decide to check the Scrum Board to see the state of things.

There seem to be many tickets stuck in testing. I also remember that on Friday evening there was only 1 ticket in progress in the Development column, but today there are 3.

That’s not right – we only have one day of the Sprint left. I need to speak to the team before they start planning for the day in their Daily Scrum.

So I send a quick message in the team channel: “We only have a day left in the Sprint and there are lots of things in progress, especially in testing. And some new items were taken into development since Friday. How confident are we to get those Done before the Sprint Review?”

One of the team members replies and suggests to discuss this in the Daily Scrum that starts at 9:30 am as usual.

I’m just there to listen in, just a fly on the wall. But my message in chat was taken into account as the developers decide to pair up with QAs to help them get testing finished first for as many tickets as possible by the end of the day.

I don’t have any meetings in the morning, but in the afternoon, me and the Product Owner are meeting up with one of the internal clients using our product – recently the relationships weren’t going so well and both sides started to get frustrated.

We didn’t really get a chance to prepare for this meeting, so I send a quick message to the PO to see if she’s available, but it seems that she’ll only have 30 minutes right before the meeting with the client. She asks me to help with preparation.

My plan is to do a very brief overview of our workflow – I don’t think they really understand how Scrum works. I make a two page presentation for this. That takes way more time than what I expected. It’s lunchtime already!

After lunch and before our client meeting, I finally have a moment to speak with the Product Owner and we finish final preparations.

The meeting goes ok-ish. The client needs to have a clear way to submit new requests and we need to communicate what will get done and when.

The meeting wasn’t extremely productive as we didn’t actually agree on the process. We have to schedule another one – next time we’ll come prepared with a proposed solution.

We have a quick chat with the PO and we realize that we don’t really have a clear triage process for requests either – we need to get the team together. Maybe towards the end of the week. I send a quick message to the group chat to let them know and agree on the best time to meet.

In the meantime I will need to work on the request submission process – that will take a while, I’ll do it later this week.

Today I wanted to prepare for the retrospective that I will be facilitating tomorrow.

I spend over an hour to do some research on what technique to use, to review our past retrospective action items, and to prepare the online board.

Considering all the research work, discussions, and reviews, the day is coming to an end.

TUESDAY

It’s the end of the Sprint. We’ll have the Sprint Review and the Sprint Retrospective in the afternoon. I need to get ready, and, of course, help the team to do the same.

I jump into the Daily Scrum, as always, just a fly on the wall. The team ends their Daily a bit faster today.

For the past few Sprints we have started a new practice with the team to spend some time after our Daily on the last day of the Sprint to get ready for the Sprint Review.

I ask the team what they are sure to be done before the Sprint Review and who would like to present what. We define our agenda for the Sprint Review together.

After that I check with the Product Owner if the client who we talked to yesterday is part of the Sprint Review because I haven’t seen them there. She says that the client is in the distribution list, but they never show up.

I decide to chat with the client about the importance of them being there, especially following up on our discussion yesterday. I have a chat with them via Slack – I’m afraid they won’t be able to read an email in time for today’s review otherwise.

I share the agenda for the review and convince them to send a representative.

As we are getting closer to the lunchtime I remind the team to update their Scrum Board – we’ll be closing the Sprint soon.

In the meantime, I start gathering the information for our Sprint Report to highlight the deliverables as well as the challenges we faced during the Sprint. This can be a great input into our Retrospective.

I also wanted to highlight an external issue the team has been facing for the past few Sprints related to a dependency on another team. I prepare a quick one-pager for the Sprint Review.

The lunchtime comes and goes, and we are getting into our Sprint Review time at 1:30 pm. We scheduled 2 hours for the meeting, but we usually don’t need that much time.

At the beginning of the Sprint Review I remind everyone of the purpose of the meeting. I also highlight that we are looking forward to some valuable feedback from the stakeholders.

I leave the rest of the presentation to the rest of the team. The Product Owner talks about overall progress towards our Product Goal and the current state of the Product Backlog. The team demonstrates the work done.

As the demo goes along, the stakeholders do not provide any real feedback. I jump in after every deliverable shown and ask some questions to get them involved in the discussion. We need to know whether this is aligned with their expectations or not.

The Review is getting quite long and I call for a quick break in the middle.

We also what we believe we are most likely to do next Sprint.

After that I talk about the dependency on another team. The team lead of that team is in the Sprint Review which allows us to immediately discuss what we can do going forward to reduce this dependency.

The meeting took the full two hours after all. The team takes a break before jumping into the Retrospective.

The Retrospective takes us almost to the end of the day.

Right after together with the team we close the Sprint and have a quick review of the Sprint Report.

It’s time to rest before the new Sprint starts.

Hey, hey, hey!

Just a quick interruption here to remind you that the New Product Owner guide is now on sale! It’s 50% off and includes 3 workshop guides and almost 60 pages of content 🤯

If you’d like to see this guide completed faster, get a copy. I’ll put the link in the description.

WEDNESDAY

The first day of the Sprint starts with the Sprint Planning. As always I remind everyone what the purpose of this meeting is and facilitate the discussions.

We start with the Sprint Goal discussion. The team is still struggling with identifying a good goal, so that takes us a good half an hour.

Once we have the Sprint Goal somewhat figured out, we start taking in the work from the Product Backlog.

The Product Owner has a list of items that she would love to put into the Sprint.

I jump in from time to time with questions like:

• Are we committing to what’s reasonable?
• Are there any dependencies we need to be wary of?
• If a ticket is too big, how can we split the work and only take what we can accomplish?

The meeting is running over an hour, as expected, so I encourage the team to take a quick break.

The team continues the discussion afterwards going into details of each task. They have difficulty splitting work into tasks, so I use this time for some coaching.

When the Sprint Planning is completed, I feel drained. I think I’ll take a quick break.

The rest of the day is quite open for me, so I check with the team if there is anything they need.

I see they want to get together to do a review of one of the tickets they want to start working on right away. I ask to be included – there might be some coaching opportunities I don’t want to miss.

In the afternoon, since I have time, I decide to work on the request process we discussed with the client on Monday.

I want to check with the team and the PO how we receive the request and I find out that each team member receives new requests almost daily from different people, plus we have a Slack channel dedicated to that. It seems we have lots of work to do.

I ask them to send me the lists of people who send new requests and start contacting them to discuss their needs. I have lots of one on ones planned for the upcoming weeks.

While we figure that out, I need to reduce the interruption to the team’s work, so I work quickly on a new board we can use in our project management tool to at least see everything in one place. I need to get it done before the end of the day.

I also ask the team members and the PO to forward me every new request they receive – for the next few days I want to document everything using our new board to give us a better understanding of what’s going on.

But I also tell the team to defer any new requests to me and the Product Owner and not agree to work on something adhoc.

The day quickly ends without me even realising it.

THURSDAY

While I’d love to join the team’s Daily Scrum, I have a Scrum Master Community of Practice to run this morning.

This is an important meeting we have organized with all Scrum Masters in our department. Luckily, I’m not presenting today, but I usually host it anyway.

We usually spend an hour on the working session on a new topic, and then another hour for a Lean Coffee to help each other resolve challenges.

In the second part I talk about the new requests coming in our way and how I’m working on a new process to make this smoother.

Another Scrum Master tells me that she has some process created already, maybe I can leverage that. We decide to meet right after lunch to review together.

One of the Scrum Masters tells us he’ll be on vacation next week and is asking for someone to replace him at least for the Retrospective. Since I have already worked with his team before, I volunteer.

I send his team a quick message in their group chat to say that they can reach out to me while their Scrum Master is away.

As I open up the new requests process that I started working on yesterday.

But I receive a message from a team member. It seems that a new request came in he sent the person to me and the Product Owner as I asked. But this person got a bit angry about this and started messaging the team member directly with a lot of insistance.

I ask the team member to turn off their notifications – I’ll take care of it. I let the Product Owner know of the situation and I quickly create a chat with the requestor, PO and me.

That discussion drugs in for a while, and, of course, it gets escalated to our Director of Engineering. So I’m sitting on three chats at once: with the PO, with the requestor, and with the Director.

To stop playing the broken telephone, I organize a meeting with all of us at once to discuss our product priorities, show our current Product Backlog, and agree on next steps.

I have to move my meeting with the other Scrum Master to the end of the day as we need to get this problem resolved first.

Finally, we come to an agreement for this particular request – it will be put in the next Sprint. But it is also made clear that this was a one-time exception. We’ll need to monitor this situation in the future.

Wait… it’s 4 pm already?

I have my last meeting with the Scrum Master to review her requests process and take some notes. The end ends in no time.

FRIDAY

Happy FriYAY!

On Fridays the team has their Backlog Refinement meeting in the morning, right after the Daily Scrum. I jump in to listen, facilitate and coach if needed.

I also know that the Product Owner has a prioritization meeting with the rest of the Product Team and I decide to join as I need to have a better understanding of the expectations set on the team. I can bring in additional information about the team’s progress and external challenges they are facing.

I continue to work on the requests process that occupied my whole week in between my regular one-on-one meetings with the team members.

It’s a pretty chill Friday as I get a chance to catch up with everyone and takes some notes on potential improvements as they share their challenges and frustrations.

But they also share positive changes, like the fact that they are finally not being interrupted every 5 minutes – they are excited about this new process.

However, we were not able to meet to discuss our triage process – this is something we’ll think about next week.

I get some time in the afternoon to collect my thoughts and do some research. There are a few new facilitation techniques I wanted to learn, and a couple of cool tools for team health assessments.

And that concludes my week.

This was a packed week, wasn’t it?

Well, not every week is like that, luckily.

Sometimes you’ll be running around from 9 to 5 with no time to go to the bathroom (true story!).

And sometimes you’ll be able to dedicate more time to research, observation, and… thinking.

Compiling your thoughts, reflecting on your work, planning improvements – these are essential parts of jobs like Scrum Master.

Don’t pack your day with meetings so that You can quickly reply to coaching opportunities and some occasional fires.

If you are looking for tools, templates and materials on how to be successful as a Scrum Master, you should check out my store. Don’t forget about the special discount on the New Product Owner Guide – it’s 50% off!