Ok, you already read about the To Do list for Scrum Masters, so why are we mentioning it again? Since the Scrum Master’s To Do list is a bit long, I am bringing you its second part.
Today, we will look at these steps from the list:
- Conduct the Planning Poker if necessary.
- Ensure that User Stories that are not Ready do not enter the Sprint Backlog.
- Help set up the Sprint Plan.
- Help set up the Sprint Goal.
- Keep the event within its time-box (preferably shorter).
Conduct the Planning Poker if necessary.
This may be necessary if we reach the point where we took all the User Stories that were Ready into the Sprint and the team still has capacity for more work, or if it is necessary to refine the User Story because there are changes in the scope of the User Story or there is a new information that could influence the User Story. In this case, we are taking another User Story that is in the Backlog and refining it into the Ready state. One of those steps is also estimating the effort. Each team member should have the chance to say how big the User Story is without being influenced by their colleagues. The best way to ensure that is Planning Poker. (We’ll get into this topic when we talk about the Perfect Planning rules.)
Ensure that User Stories that are not Ready do not enter the Sprint Backlog.
You shall not pass! Especially if you are a User Story that is not Ready. And the Scrum Master has to ensure that. User Stories that are not Ready will just create trouble within the Sprint. Because if they are not Ready, they may not be clear, they may not be possible to test, they may not have value…and we do not want any of that. (More on this topic when we get into the Perfect Planning rules.)
Help set up the Sprint Plan.
A Sprint Plan is in other words, it is the roadmap with the steps you have to take to reach your destination. It is good to know and realize which steps you have to do first to avoid back-tracking or getting lost on your journey. This is not done by a single Developer, but all together, because sometimes, the work of one person has to be delivered before someone else can start working on their part of the User Stories within the Sprint. The Sprint Plan should be finalized right during the Planning so that the development within the Sprint is smooth.
Help set up the Sprint Goal.
Each Sprint has to have its Sprint Goal. The reason why is to clearly communicate to the Stakeholders the expected results of the current Sprint. If the team is not able to set the Sprint Goal, it lowers their trustworthiness because it indicates that even they do not know what they are working on.
So, if this is the situation, it is up to the Scrum Master to help the team realize the bigger picture of the Sprint, what the delivered User Stories mean and what the product increment will be after they finish the User Stories that they took into the Sprint.
Keep the event within its time-box (preferably shorter).
The Scrum Master is the one who keeps an eye on the clock during meetings. The Planning should be no more than 4 hours. Yes, 4 hours, I know! (And imagine: in the Scrum guide, it says that the time-box for Sprint Planning is 8 hours. We have only 4 because our Sprints are just 2 weeks. Scrum assumes 4-week Sprints.) But it is a maximum. If everything is ready—the User Stories are prepared and there are no last-minute changes before Planning—then Planning can be done much faster. From my experience it can take less than an hour. If that is not the case, the Scrum Master has to ensure that the meeting will not take longer than 4 hours. If the team is not able to plan the Sprint within such a time-box, in my opinion, they are not able to plan in a longer amount of time either, and I think that giving them more time would not be productive anyway.
So, this is everything in the To Do list for a Scrum Master. The thing that we are missing is the To Do list for Developers. That will be in the next article.
Have courage and be kind.