Typical Day of a Scrum Master (Part 2)

Woman typing on a computer with coffee cup

The following is an accurate representation of what my typical day/week looks like from the perspective of a Scrum Master. Names, titles, and project details have been altered to preserve the anonymity of my fellow coworkers and to avoid sharing any sensitive company data.  Rather than highlight every single repetitive meeting, I sampled some of the most important meetings from the week.

Tuesday 9:30am, Product Owner/Scrum Master Joint Meeting

Every Tuesday and Thursday morning, we hold a joint Product Owner/Scrum Master meeting so that we can discuss what each of our teams are working on and offer help to teams who may need assistance from others. Working in a complex environment, it is very easy to lose track of what other teams are currently engaged in. On this particular morning, I discussed the challenges of working with one of our offshore development teams that was currently helping the platform team with automation stories. Because of the time difference and distance, it has made it very difficult to ensure that the offshore team understands the work and is comfortable with how to complete it. I asked for advice from fellow Scrum Masters and Product Owners who had experienced similar issues in the past. Overall, it is a great opportunity to help each other through challenges that each team is facing. I left the meeting with a few tips on what our team could do better to keep the communication open between the local and offshore teams and better accomplish the mission at hand.

Tuesday 11:00am, Leadership Meeting

         One of the most important meetings that I look forward to every two weeks is our leadership meeting. It offers a chance for my Product Owner and I to sit down with our director and discuss ways to improve our team. We talk about everything from team dynamics, current sprint work, and topics that may affect our team in the future. During this week’s leadership meeting, we spoke heavily about to improve our stand-ups to ensure that everyone is engaged and getting something out of the meeting. It is so easy to go through the motions and leave the meeting without actually getting any value from it. Our director offered us advice on how to structure the meeting to elicit better responses from some of our quieter team members. We left the meeting with a few new items to work on and would report back at the next meeting with our progress.

Tuesday 1:00pm, Backlog Grooming

         This may be one of the least exciting meetings throughout the week but it is definitely one of the most important meetings. We use the backlog grooming time to break down stories in our backlog and prepare them for the upcoming sprint. It is crucial that the team takes this time seriously so that all the stories have adequate details, acceptance criteria, and are overall well defined. We used this last backlog-grooming meeting of the sprint to finalize a few stories that we would be working on in the next sprint. Although the Product Owner leads this meeting, it is vital that the Scrum Master attends and ensures that the right questions are being asked and that the team members truly understand what is expected from each story.

Tuesday 4:00pm, Platform Team Demo

I always get excited on demo day because it allows the teams to show off their most recent work to other teams and a few vital stakeholders in the company. This sprint’s demo was especially exciting because the platform team unveiled a new tool that allows developers to quickly spin up multiple virtual machines with the software version of their choice in a matter of seconds. The process to do this before was always agonizing since it required many different steps and multiple programs to make it happen. The room was packed to see this new tool and all the developers left the demo extremely excited knowing that they would be able to save hours every single sprint because of this brand new tool that was now completed.

Tuesday 4:30pm, Platform Team Retrospective

Immediately following our team’s demo, we hold our retrospective meeting to discuss the positives and negatives of the team’s completed sprint. As a Scrum Master, I take a lot of pride in facilitating this meeting because I know how important it is to reflect on our performance. I encourage the team to be as honest as possible and find ways to constantly improve. One of the reoccurring points that we discuss every sprint is how to stabilize our velocity and ensure that we are not consistently rolling over stories to the next sprint. It is all too common for development teams to take on more work than they can handle and then find themselves unable to complete all the work for the sprint. During this retrospective, we talked about ways to better size our stories so that we don’t run into the same issue in future sprints. At the end of the meeting, I published all of our comments on our team’s wiki page so that we can review our thoughts at future meetings.

Come back soon for Part 3 of the series…