We all know that there are 3 roles defined in Scrum: Development Team Member, Product Owner, and Scrum Master. There is no doubt that Development Team Member is a full time job, and that Product Owner probably is too. At least, most of us can imagine what this role implies that makes it full time.
What about Scrum Master?
During a recent project my colleague Vyacheslav Moskalenko and I – together with a group of SMs and PMs – tried to figure out what lies beneath this role and how much time it takes to be a Scrum Master.
A Scrum Master’s Scheduled Checklist
Let’s start with the mandatory meetings that we have in Scrum. It is obvious that we need to prepare ourselves and the team for these meetings. In order to be effective and efficient, every meeting needs:
A clear goal and agenda.
A proper setup (invitations sent, room booked, attendance taken)
Facilitation (good facilitation requires not only skills, but a well-prepared facilitation plan)
A solid follow-up with meeting minutes, including decisions taken, problems raised, etc.
Along with meeting rules, each meeting in Scrum has its own clearly defined goal. It means that while preparing the agenda for the meeting, the SM should also find out what the team needs in order to efficiently achieve those goals.
So, let’s write down a minimal list of items for every meeting we have:
The Sprint Planning
Make sure that the entire Scrum Team is participating in Sprint Planning.
Before the Sprint Planning, make sure that the Product Backlog is transparent, that priorities are relevant, estimates for PBIs are provided and all the PBIs that are about to be planned have passed the PBR and comply with the readiness criteria you use within your Scum Team.
See that the Development Team is focused on respecting the Product Owner’s priorities.
Help calculate team velocity.
Prepare to facilitate the group. What would you do if the Development Team didn’t have enough refined PBIs? What if the PO is bringing new items with unclear requirements?
Conduct the Sprint Planning session. Make sure that the Development Team has answered two questions: What is included in the Sprint Goal, and how it is going to transform PBIs into finished increments?
Make sure that the Development Team has created a Sprint Backlog which is easy to explain to the Product Owner and Scrum Master. For example, the Sprint Backlog can be in JIRA and on a Physical Board.
Make sure that if there are PBIs which were not possible to decompose and properly plan, the Development Team is creates meeting notes with all questions. In this case, the team can create some analysis tasks for follow-up.
The Product Backlog Refinement
Schedule regular and recurrent Product Backlog Refinement meetings, book a room and send invites to the Development Team and the Product Owner. A one-hour PBR meeting on a weekly basis is a good balance for the Scrum Team.
Review current descriptions of the Product Backlog items (PBIs) with the Product Owner, and make sure that the Product Owner will be able to explain PBIs from the business perspective and understand the context.
Before the PBR meeting, clarify with the PO 5 to 10 product backlog items to be discussed during the meeting. Usually the preference is to refine PBIs without estimates at the top of the list.
Make sure that when the Product Owner is changing priorities in the Product Backlog it is timely communicated to the Development Team
Before the PBR meeting, decide if there are any issues that the PO may need to clarify with business stakeholders.
Create an agenda for PBR meeting and refine the facilitation plan.
Conduct the PBR if needed. Does the team have all the resources to complete the PBI within a sprint? Do all of the PBIs have clearly identified “Who”, “What”, and “Why” parts? Do all of the PBIs have estimates?
Send the PBR meeting minutes, including action items for unanswered questions and action items for unclear requirements.
Help the Product Owner to maintain the Product Backlog in a transparent state so that the business stakeholders can easily understand the planned value. Teach the Scrum Team effective PBR techniques, such as, INVEST criteria, Specification by Example, BDD, User Story, Job Story, Estimation in Relative Story Points, Affinity Estimation, Poker Planning, Release Roadmap, Story Map, User Story splitting patterns, etc.
The Daily Scrum
Make sure the Daily Scrum meeting is always occurring at the same time and the same place.
Make sure that the latest information from the Product Owner in terms of priorities or requirements is available for the Development Team by the Daily Scrum.
Check the progress of the Development Team. A Burn-down chart and other projection techniques might be helpful to see progress.
Teach the Development Team how to negotiate with the Product Owner if the progress is going much slower than it was planned initially
Conduct a Daily Scrum, if needed. Teach the Development Team to conduct the Daily Scrum without a Scrum Master. Ensure that the Development Team is focused on the Sprint Goal.
Ensure that the Sprint Backlog is in a transparent state and that it explains the plan for the next 24 hours.
Ensure that all the raised problems are followed-up with the relevant group of people.
Ensure that all impediments are captured and solved within a day. For some items in the impediment list, the Scrum Master may take personal responsibility.
The Sprint Review
Prepare the stage. If needed, find a relevant room, set up a video/audio conference call as well as screen sharing with access to a demo environment and to the Product Backlog.
Ensure that the Product Owner and the Development Team have clear agendas and goals, keeping in mind that the Sprint Review should help the stakeholders provide reliable product feedback to the Scrum Team.
Send meeting invitations and make sure that the Product Owner has invited stakeholders to the meeting. If necessary, explain to stakeholders why they have to participate.
Ensure that the Development Team is going to demonstrate only DONE items to stakeholders. If needed, help developers prepare and use appropriate wording.
Remove all possible impediments that are preventing the Development Team from setting up a proper demo environment.
Help the Development Team prepare a good presentation that is useful for stakeholders. The presentation may include Sprint metrics, a list of organizational impediments, a list of process improvements and other information which may increase the transparency and trust between stakeholders and the Scrum Team.
Prepare to facilitate the Sprint Review meeting. Discuss with the Product Owner the best way to lead the meeting as well as what is and isn’t an appropriate communication style with business people. Reflect on what worked well last time and what can be improved during the next Sprint Review based on recent feedback from participants.
Make sure that the Development Team is ready for the Sprint Review meeting. A demo rehearsal is good practice.
Conduct a Sprint Review (including taking notes of every issue raised, while creating and sending meeting notes).
The Sprint Retrospective
Set up the retrospective meeting (find the room, send the invitation).
Decide with the Scrum Team whether to invite the PO to the retrospective.
Decide with the Scrum Team what the focus of the upcoming retro should be.
Create a facilitation plan for the retrospective.
Conduct a retrospective.
Send the meeting notes.
Ensure that the Development Team updates the Improvements Plan after the meeting.
Let’s calculate the time spent on this. Usually it takes a minimum of 15–20 hours a week, if the Scrum Master is diligently taking care of all the activities listed above for just one team. It can take even more time, depending on the number of impediments and teams. Do you have a usable increment by the end of the Sprint which can be released immediately after the Sprint’s conclusion? If not, then it is a full time job for the Scrum Master to prepare as many presentations and go through as many negotiations as required to cause the organizational change needed for delivering the DONE increment. The Scrum Master is accountable for removing all the organizational impediments that are hindering the Scrum adoption. Is there anything left?
Yes there is. Maksim Gaponov has shared a slide describing the SM areas of attention:
If you look carefully, you will see that the hours above only imply 1/6. But I believe it will be unfair not to let him speak, so I’ll keep my mouth shut until next time!
How To Use The Checklist
If you would like to use the checklist above, please review the items and add the things that you believe are missing. Then, decide when you are going to do all these things and schedule them in your calendar. Now when you come to work you have a list of action items that are not to be missed.
If you want us to help you with setting up the Scrum Master schedule checklist for your project, you may request it from the Luxoft Agile Practice, or if you want to explore the role of the Scrum Master please enroll in our certified Professional Scrum Master training.
Here are some links to consider on the topic above: one, two and three (you may find more if you need).
Strona korzysta z plików cookie w celu realizacji usług zgodnie z Polityką prywatności.
Możesz określić warunki przechowywania lub dostępu do cookie w Twojej przeglądarce lub konfiguracji usługi Akceptuj