June 13th, 2019 | Updated on June 30th, 2022
Assuming you are fresh graduate and you’ve completed your CSM training, you’d have a basic understanding of how Scrum should function, and what roles you can expect. Therefore, when you are finally designated as a Scrum Master, you have that exuberance that comes with climbing the first mantle.
However, this exuberance doesn’t usually last long. Once you’ve seen your fair share of daily stand-ups, doubts start creeping into your mind. As the last day of the Sprint approaches, thoughts whether the team will be able to deliver on the promises, ensure quality consistency, make the final presentation go smoothly, fulfill all the items in the backlog, or meet all the specifications of the product owner will arise.
The other thing that is going to bother you when you’ve seen the daily progress first-hand in the stand-up is whether the team has really performed or not. You’ll start to wonder if you’ve missed something, or if you’ve not foreseen certain impediments.
It is absolutely natural to have these questions because the amount of uncertainty involved in bringing the team until their next Sprint is humungous. Asking questions can help you foresee and plan to mitigate issues even before they arise. Therefore, below are the standard problems and how it is best to be wary of them.
1. Commit to Reasonable Work Schedules
As a ScrumMaster with a CSM certification, your job is to ensure that the team picks enough amount of work. During the planning phase, as the team members commit to schedules from the backlog items, your role involves questioning them, challenging their assumptions, and suggesting/guiding regarding the amount of work they can take on. This doesn’t mean you offer the final word.
Your role is to make them see your perspective, and that’s important. Usually, the team members can be right regarding how much work they can handle. But it is your role to keep sight of the larger picture. Therefore, splitting the work sufficiently, and ensuring no one is overloaded, or is working beyond rational expectations is your work as a ScrumMaster. This way, you can foresee problems that would likely affect the proper deliverance.
2. Managing Expectations
There is usually a gap between what the product owner is asked for, and what the designers understand, and this could affect the final deliverance. Your job is to ensure that all of them remain on the same page. This involves compromises and pulling strings. One suitable way to do it is to make sure, after the planning meeting, that everyone remains in sync regarding individual items in the backlog.
For more complex projects, this can become a hassle. One way to mitigate it is to have demos along the way. These need not be formatted perfectly. They are meant to be extremely informal so as not to waste time. This usually involves only those team members that have worked on the topic of the demo.
This gives the PO an idea of where the project is going and managing expectations as well. In case the PO is unavailable, or the team members can’t find matching schedules, one other way to circulate screenshots to help everyone understand the scope of the work actually done.
The point of this exercise is to invite feedback before it becomes difficult to incorporate and to ensure the communication becomes critical in executing the project. While some people may feel that the work would be undermined with these short demos, instead of one grand demo, it is your job as a ScrumMaster to bring the team members around
3. Follow-Up Planning To Planning Meetings
There might arise some drags regarding the technical feasibility of the actual project, and whether the estimates are suitable or not. In these cases, it is advisable to have the meetings way before the start of the next Sprint so that the PO will have time to share as many specifics as possible, reducing the need to estimate and alter the feedback later. This doesn’t, however, end here. There are certain situations, after this, where the team members realise the gravity of other members depending on them.
This doesn’t mean that you micromanage the team, or supervise every action. The team should ultimately manage themselves. Your role is to ensure there are no impediments, and that the schedules, including external ones like infrastructure, are managed to create the least external influence.
4. Delivering With Scrum
It should be remembered that Scrum is an internal affair, and no one pays bills for how well the team is managed.
The client only concerns himself with the deliverables and the budget. To get the work done in a proper manner, Scrum is a great enabler, and you should focus on acting as a coach rather than as a supervisor to the team.
