Scrum Master Tips: One Practice to Identify and Reduce Risks During Sprint Planning

Some time back,  I was in a Sprint Planning meeting with my team.   Listening to the conversations, it was clear that the team had a pretty good idea on what to do and how to do, but, I sensed that there quite a bit of ambiguity and uncertainty about how the planned items might be executed during the Sprint.  As we were beginning to wrap up the Sprint Planning meeting, I jumped in and asked ” Imagine if we could time travel and go to the future – to the end of this Sprint.  We look back at our Sprint and it was a total disaster. What are the things that happened in the current Sprint that made it a failure? ”

The team started calling out things. And I started making a list. Then I asked them to call-out/classify things as “In out control”, “somewhat in our control”, and “not in our control”.  Naturally, my next question was, “What plans do we currently have to mitigate things in our control and things that are somewhat in our control?” A discussion ensured and the team identified a few other things that they had not accounted for earlier, and created a plan on what to do if something failed, how to coordinate, execute, and stay in sync for some of the high-risk items. They also created a check-point (dates) and added tasks to their Sprint Backlog (i.e. whiteboard. Like any high performing team, this team stays away from electronic tools for Sprint Backlog) and a few people volunteered to talk with other teams to see how they could mitigate the risks. As a Scrum Master, it gave me insights right away into organizational impediments that I need to watch out for and to work on (the list of items in “out of our control”).

I call this Sprint “Pro-spective” or “Future-spective” (as opposed to retrospective) i.e., actively looking back, but from the future.  I do not use this technique every Sprint, but where there is a quite a bit of ambiguity or lack of shared understanding, I tend to use this technique.

Why this works?

• Explicitly visualizing the future, and stating that the sprint was a disaster helped amplify the “weak signals” in the system.  There were no wrong answers. Some of the things that could go wrong were ambiguous and not everyone had a shared understanding. Stating the Sprint was a disaster could help them create a storyline on how a sequence of things could go wrong which will make the sprint a disaster.
• It created a shared understanding of the risks for the team and a plan to tackle the risks which were in their control and somewhat in their control
• As a Scrum Master, it gave me a list of things I need to act on right away, instead of waiting for the team to start executing the Sprint and watching out of impediments. I could proactively see what I should do to reduce /eliminate the risks so that the team can achieve their Sprint Goal.

Hope you find this useful !!