Scrum Masters play a critical role in ensuring goal alignment, identifying risks, removing bottlenecks, and keeping sprint backlogs on track. Ask these often overlooked questions to set your agile team up for success.
By Sheyinka Harry
As the servant leader for an agile team, the Scrum Master does much more than facilitate meetings and remove roadblocks. Scrum Masters spend a lot of their time roaming about the room, virtual or in person, listening to discussions and challenging their teams. One of the most remarkable aspects of servant leadership is being put into a position to help your team develop and perform as highly as possible. A part of satisfying this is by leading teams to make the best decisions based on skill set, parties involved, resources, etc. This does not mean telling them what to do. It instead means asking questions during the different interactions to challenge your team’s own decisions. Challenging their decisions isn’t about undermining their expertise or knowledge, but rather ensuring they have taken the proper steps to this point of recommendation.
Discussed below are some of my favorite questions to ask as a Scrum Master.
During Backlog Grooming:
1. How are we scoring effort?
It is important for Scrum Masters to remind the team of the metric (t-shirt sizes, hours/days, story points) being used for estimation of effort, as well as what is being accounted for in the score. Typical considerations when estimating effort include:
- Developer effort;
- Quality Assurance effort;
- Lead time between moving parts; and
- Third party coordination.
This ensures that everyone is on the same page. It can ultimately result in more aligned points of effort being awarded – if this is understood and agreed upon by all team members. You can also identify bottlenecks and make decisions accordingly.
During Sprint Planning:
2. Do we have all the information needed to get these tickets completed?
Before we start a ticket or even pull it into a Sprint, we always want to ensure that the team has all the information they’ll need to get done. This removes the possibility of starting a task with a blocker. It is also important to ensure the team has a clear understanding of the “what” they are about to solve.
Having what you need is determined by looking at the following:
- Clear acceptance criteria that can guide the implementation by the developers and the subsequent validations by the QA.
- Supporting documents (designs, schemas, instructions, “wording”) are made available before it is slated to be actioned. Having these details ultimately ensures that a story/product backlog item is Ready.
3. How will we complete the Sprint Backlog?
Going into Sprint Planning, Scrum Masters usually facilitate the team discussions about what the Sprint Goal will be and ensures that the team looks at the priority Product Backlog items to be tackled to achieve it. In previous Backlog Grooming sessions, the what of these priority items would have been clarified by the Product Owner and agreed upon as understood by the team, or sent back for further clarification. This is great, but simply knowing what to do isn’t enough. The team now needs to have a more detailed discussion around how they’re actually going to satisfy the acceptance criteria of the priority items. This step is often missed by teams, which inadvertently causes issues in execution. Skipping this step often results in:
- Unaccounted for pieces of the technical equation;
- Testers not knowing how to test the implementation;
- Too much time spent going down the rabbit hole; and
- Overcommitment of tickets.
Doing a dissection of the tentative Sprint Backlog items prompts the team to take the following into account:
- What frontend considerations do we need to take into account?
- What backend considerations do we need to take into account?
- What QA considerations do we need to take into account?
Basically, what are the actual needs for this piece of work? Determining this provides insight into not only the work that will go into satisfying the acceptance criteria, but also who will be needed to get the Sprint Backlog item to the finish line.
4. What can we reasonably accomplish during this Sprint?
When looking at the tentative Sprint Backlog post team assignment and sub-tasking, a decision needs to be made regarding whether or not the team can actually accomplish everything. We now need to put things into perspective by looking at factors such as the average velocity and the actual availability of team members. With availability, consideration must be given to any upcoming time off, external meetings, and outside commitments.
Knowing how much time you need to allocate elsewhere lets team members know just how many hours or days they should dedicate to getting work done in the Sprint. This refined view of actual availability can then be applied to determining the team’s joint capacity. As a Scrum Master, I love emphasizing joint capacity with my teams, as we often fall into the problem of developers taking on a load of tickets to complete without sufficient QA resources available to get them done and ready for demo. What needs to happen is this: The developers look at what they can get done, and the QAs also examine if the workload is feasible. This reinforces the importance of getting a story done within the Sprint it was started. This takes joint effort from the team. Oftentimes, there are reviews necessary outside the actual testing and validation of the implementation, so we want to look at the full workflow to get items completed rather than look at them disjointedly by role. By doing this, what do we know we’ll get done without a shadow of a doubt? Anything else can be noted as stretch goals.
During Daily Standup:
5. Is there any new knowledge that we need to take into account?
As we work, we uncover new things that lead to the evolution of the Product Backlog and the actual product. These can take the form of a new direction based on insights from a technical Spike, a new design approach, or missing requirements needed to complete the user flow. Whatever the case, any new stories uncovered out of what is currently being worked on need to be created. We want to ensure that we are filling any gaps in our execution, and that these details are captured in the Backlog ahead of our Grooming and Planning sessions.
6. Are there any risks to the work we committed to?
As the team works on getting their tasks done, there may be unforeseen circumstances that take their attention away from this goal. As time progresses, it is important for Scrum Masters to do a temperature check to see if things are still on track. Can we still get everything done by the end of the Sprint? If the answer is no, there will need to be follow-up discussions with the aim of either Resolving, Owning, Accepting, or Mitigating these risks. If nothing can be done to remove the risk and get back on track, a discussion around a possible shift in priority can be made.
For my teams, these checks are done at the mid-Sprint, T-2 and T-1 days before Sprint Review. At these points, based on the risk and how much time is needed to complete the task as opposed to time left in the Sprint, the team member(s) are asked to shift their focus to helping the rest of the team get achievable tickets completed.
Pushing your team to be great and make the best decisions is no easy task. However, it can become less complicated when you ask them the right questions. Once you start asking these questions, you will see the true effectiveness of your team and the power of teamwork. Ask them enough times, and I guarantee you’ll see a change in their thought process and execution.
About the Author
Sheyinka is an Advanced Certified Scrum Master and Senior Agile Consultant at QualityWorks Consulting Group. Over the last few years, she has worked with product development teams across the US, Latin America, and the Caribbean to help streamline and optimize their software delivery process and build products their users love. She has significant experience in the finance and e-commerce space and is passionate about helping organizations achieve their goals through agile transformation.
Check out part 1 of the Agile Questions series for Six Powerful Questions Every Agile Team Member Should Ask.
Check out part 2 of the Agile Questions series for Stakeholders: Three Powerful Agile Questions You Should Be Asking
Check out part 3 of the Agile Questions series for Powerful Agile Questions Every Product Owner Should Be Asking