Good morning! Thanks for joining me today. I’m excited to take you through a day in my life as a remote Scrum Master. I am based in New York state, and my company is headquartered in San Francisco, with about 50% of my colleagues working hybrid out of our SF office, and the other 50% working remotely around the US. I work on two squads, let’s call them the Blue Team and the Green Team.Â
9:30am - I log onto my work computer and check my Slack, followed by my emails. Since most of my team is 1-3 hours behind me, I like to take long, slow mornings on my deck, having breakfast while watching the birds in my backyard. Most of my other east coast team members do the same thing, though some love to start early and take advantage of the quiet time for focused work before others get online. I like to run through my calendar for the day and start a to-do list.Â
10:30am - After catching up on Slack, email, and my calendar, I’ll grab an hour or so to work on a focused project before my meetings start for the day. Right now, I’m trying to help my company adopt the practice of using OKRs: Objectives and Key Results to get better at setting and tracking goals. This is an initiative that my Scrum Master Chapter, the group of 5 Scrum Masters in my organization, has been collectively working on after reading Measure What Matters by John Doerr. Right now I am working on building an OKR guidebook to circulate within my company and help our Scrum Master team coach their Product Owners and leadership.
12:00pm - It’s time for the Blue Team’s Daily Scrum. We’ll all join a Zoom to align on our plans for the day. I’ll share my screen with our Jira Board, and start the meeting by highlighting the Sprint Goal and inspecting our progress towards it. I'll ask the team whether there risks or blockers that are threatening the Sprint Goal, and I’ll write down any that they have. Today, our Test Engineer shared that she seems to no longer have access to a testing suite she needs and it is blocking her ability to test the increment we have built. I take note of this and let her know I am on it.Â
12:15pm - After the Blue Team’s Daily Scrum, I immediately file a Helpdesk ticket with our IT team requesting the test suite access be reinstated for my Test Engineer. She’s currently testing another bug for the team, and I’m glad to be able to perform this simple task for her so she can stay focused on sprint work.
12:30pm - It’s now time for the Green Team’s Daily Scrum. They report that all is going well and they are on track to complete their Sprint Goal. It’s the second Thursday of our sprint, and we have a practice on this team where if we are on track to meet the Sprint Goal by the second Thursday, we take a Learning Friday the next day. This is something we created out of an action item from a Sprint Retrospective. We’ve all seen the research from 4dayweek.io showing that a 4 day work week is superior to a 5 day work week in nearly every way. Our Scrum Master Chapter has been advocating to our company’s leadership team and board to adopt a 4 day work week, since the data shows that it would help our business and culture immensely. Unfortunately, this seems like it will be a long-fought battle and our Executive Team is not there yet. We will continue to persist until we burn out and eventually get jobs at other companies that already have a 4 day work week. Anyway, based on the research around working one fewer day per week, the Green Team wanted to experiment with taking a Friday to learn, rest, and recuperate every other week if they are on track to meet their Sprint Goal by the time their Sprint ends on the following Wednesday. We experimented with this for 3 Sprints and then used our Jira reports to examine how it impacted our work. We found that our velocity actually increased, largely because holding ourselves back from working the final Friday of the sprint prevented team members from pulling in new stories from the backlog once they handed off their development work on the increment to our Test Engineer for QA. Often times, they would make this handoff, start something new, and then when the increment came back to them with a bug that the Test Engineer had found, they suddenly had to split their focus between the new story and the old one. This ended up slowing down our Code Review and QA processes because there were now too many stories moving across our Sprint Board at once. The result was that by splitting our focus and trying to start additional work before releasing our increment, we actually put the Sprint Goal at risk and ended up missing it many times. Now we’ve learned that taking a day to not work helps us maintain that focus instead of starting something new just because an engineer is not occupied at all times.
12:45pm - After The Green team’s Daily Scrum, I take a break for lunch. I try to close my laptop and eat outside with my partner, who also works remotely. It’s a great moment to reset and disconnect from work.Â
2pm - After a long lunch, I have an afternoon full of meetings. My first one is a Scrum Basics training that I do for any new hires that have started on one of my teams. We recently hired a new Graphic Designer for the Blue Team and a new Software Engineer for the Green Team, so I now host a joint session to give the two of them an overview of scrum and answer any questions they may have.Â
3pm - Next I have an hour long meeting with all of the Scrum Masters and Product Owners in my organization. It’s led by our Director of Product, and unfortunately it’s a meeting that provides little to no value to its attendees. It’s essentially a round robin of each Product Owner sharing the high-level of what their team is working on that sprint, and discussing any potential conflicts or coordination needed between teams as a result. All of this information can be found in Jira, and the release coordination piece is covered by the Test Engineering Chapter’s weekly meeting, so all the content of this meeting is redundant. Our Scrum Master Chapter talks often about how this hour every week is a waste of time and how we would like to eliminate it. Our Director of Product has so far not been open to this message from us, and we believe he feels the need to hear what everyone is doing, possibly for control reasons, and also because he doesn’t seem willing to go into Jira and look for himself. We would like to explore why he feels this way and how we can coach him into a better option so we can save this hour for all thirteen attendees.
4pm - The Blue Team has a 90 minute Backlog Refinement meeting once a Sprint. While this isn’t an official Scrum event, it is a complementary practice that this team has adopted because it works for them. Our Product Owner leads us through the stories at the top of the Product Backlog in Jira, which are our next priorities. After she explains each one and answers questions, the Development Team will use a Planning Poker Zoom plug-in to story point each story. Today we get through six stories and feel pleased with our progress.
5:30pm - I finally have finished my meetings for the day and turn back to Slack to check on messages that have come through for me. The IT Helpdesk has approved the testing suite access request for my Blue Team’s Test Engineer, and the ticket is routed to her manager for final approval before the request can be granted. I Slack him with a link to the ticket and ask if he could approve it so that the team’s Sprint Goal is not blocked for an additional day tomorrow. He does, and the access is granted.Â
6:00pm - I close my laptop and finish work for the day. Being on a remote team distributed across 3 time zones means I finish work at different times depending on the day of the week. Today and tomorrow are the only two days where I should need to work until 6:00, and while some meetings may be scheduled until 7:00 or 8:00 pm my time, I have set a boundary that I will not attend anything later than 6:00pm for me. I can already smell that my partner is cooking something garlicky and delicious, so I turn out the lights in my home office and shut the door for the night.