A day in the life of a Scrum Master
Scrum Masters come in many forms, shapes, and sizes. They are as different as the companies they work for and the jobs they fulfill. But are these differences only skin deep, or are these jobs truly different? It feels impossible to say, so I decided I wanted to know what other Scrum Master jobs look like and how they are positioned in the organization. I asked a few of my fellow Scrum Masters to share a DILO — a day in the life of a Scrum Master. From (half) hour to (half) hour a narration on what you are doing during a typical day of a Scrum Master.
If you are a starting Scrum Master or want to know what being a Scrum Master could be like, this article is for you. Although these are two specific examples of two specific days of two different scrum masters, it should give you a feel of what it is like. Below are the stories of Alex and Jasmine. After that, I will share my conclusions.
Alex at the footwear and leisurewear retailer
I’m a Scrum Master (my official title is Delivery Manager) for a footwear and leisurewear retailer, working across two separate teams of around seven. We focus on the checkout process of the website and our new strategy of Composable Commerce (CC) as an enabler for the Omnichannel strategy. The CC team just wrapped up our Proof of Concept and is into our first production sprint so we’re still finding our feet with complementary ways of working. Scrum is very much at the heart of how we operate as it allows us to build, test, and iterate on ideas and gives us the flexibility to change course quickly if and when needed. The teams are a mix of seniors and juniors so each of us has a critical role to play in the professional development of our colleagues.
08:00 — Log on, checking emails, and Azure DevOps for ticket and build statuses.
08:30 — Reviewed a Miro board for an upcoming interview session for a fellow SM. I chatted through with the Hiring Manager about what looks good and what is still missing that we need to quiz on in the interview.
09:00 — Catchup with my manager. A decision has been made at the executive level on the OKR strategy for the first quarter for my team. I then spoke to the Product Owner, making sure we have data to support our product roadmap, and discussed any dependencies that need to be identified and managed to deliver against the roadmap.
09:30 — Daily Scrum. We go through our DevOps issue board; a dependency is raised on another team which I’ll take away and set up a meeting to discuss.
10:00 — Had a 1–1 with a developer, we discussed her progress in her apprenticeship, exchanged some ideas on ways of working involving BDD, some confusion around where in the tech stack her focus should be and I took some actions to chase some additional training documentation that had been promised to her.
10:30 — I’d listened to an interesting Liberators podcast at the weekend explaining 5 types of value and thought it might solve an issue we were having in framing Value to the PO of more technical tasks. I built a workshop explaining this to the team and a plan to start tracking the types of value we have delivered to make sure we are investing time in the right places.
11:00 — We’re mid-Sprint so I reviewed the last set of responses to the Team Morale survey and redistributed for the next round of answers. We’re still early in the process so the data set is not sufficient at this time to suggest patterns but there is a marked change in responses from last time. Something to keep an eye on.
12:30 — The interview begins!
13:45 — Daily Scrum for the second team. They confirm the Sprint Goal is still achievable and valid with no impediments so I leave them to it.
14:00 — I have a session with fellow SM to set up a new tool helping manage work with a 3rd party provider. We need visibility of issue statuses, raised bugs, and estimates but don’t want to over-engineer a solution. Less is more.
15:00 — Offered some coaching on what backlog refinement should and shouldn’t be ahead of our first session tomorrow.
16:00 — I built and shared our Team Charter — I wanted the Team Charter to be an output of other sessions rather than another dedicated meeting so they didn’t get meeting fatigue. We’ve discussed Roles & Responsibilities, how we measure Value, agreed on Communication methods, and our Glossary. Sitting in the middle is our Product Vision statement to remind us all of what we’re striving for.
17:00 — Time for a little personal reflection and learning — what did I do well today, what could have gone better, read a chapter on facilitation management to make progress towards our Book Club.
Jasmine in Telecoms
Hi! I’m Jasmine, A ‘Junior’ Scrum Master cross Project Manager based in London (but working remotely these days, of course). I work in a large cross-functional Scrum team of approximately 17 wonderful and talented developers, QA’s, UX/ UI designers, BA’s, FA’s, strategists, and a PO. My client is a large Belgian Telecoms company and we work iteratively on their primary customer-facing mobile application.
9:00 — Log on, check emails, *drink coffee*, check my Trello board for items that need to be completed today, items that I’m still waiting for a reply on that I may need to chase or follow up on, and any items from my ‘backlog’ that I could pick up if I have the capacity that day (could include professional development projects or non-urgent items relating to the team). Today is a Sprint Review Day so I probably won’t have time to pick up anything additional as it is a packed day. If any team members have been away or off sick I may message to check in with them.
10:00 — Daily Scrum to walk the board with the team. We use JIRA and have a board for each of the iOS and Android Developers and a ‘Danban’ board for the Designers. After walking the board, we’ll discuss ‘offline’ items that arose from walking the board that needs further discussion (in a timeboxed manner). We also use the standup for any quick announcements like absences and reminders
11:00 — Demo Prep meeting with the Devs and QA’s. We do a final walkthrough of who is demo-ing in the Sprint Review and that we have all the test accounts and access to the appropriate testing environments. I’ll have prepared some slides for the Sprint Review to introduce our Sprint Goal and what the team worked on that sprint including stories/ features, tech tasks, and bugs. The team will decide and discuss if they want to share any of the tech tasks or bugs to highlight the business value of picking up tickets like this with our stakeholders.
12:00 — Sprint Review! We all gather as a team with any additional stakeholders or guests that we may have had dependencies with for that Sprint. The team demo what was done that sprint and discusses any tech tasks or bugs that are interesting to share. After the demo, we have a look at our Release Goals to see how the current Sprint is situated and how the next Sprint will be shaped in line with the Release Goals.
13:00 — Lunch! I’m a soup and salad lady these days. I usually also go for a walk around the neighborhood to freshen up my mind as I’m consciously reducing my caffeine intake so anything that healthily stimulates my energy levels is always welcome.
14:30 — Sprint Retrospective! One of my (and many of the team’s) favorite events of the week. We start with a silly icebreaker like a Kahoot! Quiz, a few rounds of Pictionary or a Mood Check (particularly since we have been remote working and in and out of lockdowns). A new change we’ve made is to populate our retrospective board (typically a Miro whiteboard) asynchronously in advance of the event. This allows people a bit more breathing space to think of items and has resulted in much stronger engagement. It also leaves us a little more time to discuss the topics at hand. We have tried a myriad of themes and formats to stimulate different kinds of engagement depending on how the team is doing and what kinds of impediments we are facing but the template usually follows a ‘What Went Well’, ‘What Could Have Been Better’, and ‘How to Move Forward’ baseline format. We also share ‘Kudos’ which have been a nice small morale booster amidst a challenging remote working environment.
15:30 — Quick comfort break for another short walk or to get some admin done
16:00 — Sprint Pre- Planning! Led by our Business Analysts, the team has an initial discussion about what backlog items they will work on for the upcoming sprint. The team will finalize this in a Sprint Planning meeting tomorrow morning.
17:00 — The Final Hour is spent regrouping from the day. I will spend this time consolidating the board from the Retrospective, checking in with team members if any impediments came up during the day, and if there is time, reading a few Medium articles or reading some of the posts in the Serious Scrum Slack group.
Conclusion
The first thing I notice is that both Scrum Masters start and end their day very similarly — checking e-mails and todo’s in the morning, taking time to wind down, reflect and study at the end of the day. This first hour of the day is very important to both of them — Alex plans his day and sees his priorities, Jasmine quickly sees there is a day coming up with a Sprint Review, so there won’t be much time for actions or e-mails. It is also clear that the job of Alex and Jasmine is on the human side of things, there is no code writing or technical discussions in their DILO’s.
There are also differences. Alex spends a bit more time of his day on individuals in his team whilst Jasmine works more with the team as a whole. This could be because Alex is formally a Delivery Manager, but I think the difference is more practical — during this specific day, Jasmine doesn’t have time to spend time on individual coaching or meetings. She is filled with scrum events, preparing them and discussing them with the teams. A more normal day could be more comparable.
Is it self-management?
If there is one thing that is clear to me from the two stories, both Alex and Jasmine have a high degree of self-management. There is hardly anyone telling them what to do or what to focus on. They just “do” their thing with the goal to best support the team and help the organization understand Scrum. This makes me conclude that, based on everything, a Scrum Master should be able to self-manage and have an attitude towards improvement. To do the things that they think are best for the team and the position of the team within the organization. This could very well be a skill that at least all Scrum Masters should have.
