Scrum Master

"You will be scrum master of this from next week!" These are the words that you hear and then you find yourself in a mess. You really don't know what to do from next week? Your first reaction should be "Will I be a full time scrum master or a part time one?"

If you are appointed as a part time scrum master, then you will perform either coder or tester or whatever roll you are - as a routine - primary job responsibility and along with it you will also perform good scrum master duties (which are mentioned below). The constraint in front of you will be you will not be able to achieve "great" scrum master role (just because you live a real world where a day has only 24 hours and you just can not do everything in 24 hours). You can be a great scrum master if you are a full time scrum master. Also, you can be scrum master of many teams at a time, which will eat your time and will constraint you to be a great scrum master.
(Message to the company management: If you want great scrum masters in your team, then make it a full time role and make it one scrum master per 2-3 teams)
Or you can also react in a different way: "Do you want me to be a good scrum master or a great scrum master?" Of course, the answer you will hear depends on your company's budget, but let us see how you can start your journey from a good to a great scrum master.

A good scrum master's day:
1) Enforcing the time-boxes: Make sure that your scrum team follows the time-boxes like sprint, release, PSI, etc.
2) Organizing the meetings: Organize and facilitate scrum rituals like planning, demo, retro, etc.
3) Resolve the impediments: Resolve the impediments by yourself or guide the team to appropriate people who can resolve those impediments.
4) Go home and have a sound sleep.

Start asking below questions to yourself and take necessary actions to be a GREAT scrum master:
1) Is the product backlog prioritized?: This will trigger your discussions with your product owner and then product owner will run here and there to set it up.
2) Are there any stories in product backlog which are lying idle for too many days?: This will help your product owner to identify if certain stories are really needed or can be removed?
3) Are the user stories near the top of the product backlog express INVEST criteria? This will trigger more backlog grooming sessions between the team and the product owner.
4) Is the team burning technical debt at appropriate pace?
5) Is the information about sprint progress, easily visible to all the stakeholders?
6) Is burndown steady?
7) What are those things which are not working well within the team?
8) Are there any opportunities which team is not discussion, because they feel uncomfortable?
9) What new can be done in retrospective meeting?
10) What is this sprint's goal?
11) What is preventing team to be self-organized?
12) Can we automate more?
13) Is team following DoR and DoD?
14) Are we using scrum of scrum meeting for inter-team communication?
15) How good the organization is at providing career growth and motivation to scrum team members in terms of roles or opportunities or technology.

As a scrum master, you can use these as your checklists to start your journey from good to great scrum master.