Beat the blockers

Photo of Anthony de Wouters Written by Anthony de Wouters,   Feb 26, 2020

Imagine a typical scrum scene - the team gathers around the board for the daily standup, one of the team members gives his/her overview of the matters at hand. Things seem to be going well until somebody mentions a dreaded 'blocker' word. Suddenly the team panics, the ears of the scrum master perk up, and madness ensues. 

Sounds familiar, though perhaps slightly overdramatic? 

In most cases, the team eventually finds a solution but by then the damage has already been done to slow down the progress. You must change your approach, anticipate and prevent the blockers. You must become proactive!

proactive approach in blocker managements

Scrum Masters should do their best to remove and avoid blockers; the emphasis here is on avoidance. However, this is a team sport. Teams and product owners alike should manage blockers. In this blog, I will break down some areas within the scrum framework to help you shift from a reactive mindset to a proactive one.

Backlog refinements.

When refining stories and preparing them for entry into a sprint, every member of the team should ask himself these important questions:

  • What could potentially prevent this story from meeting the Definition of Ready criteria?
  • What can we do now to avoid blockages in the future?
  • How can we reduce uncertainties and risks? 

Consider the activities such as lining up architectural approval, confirming release dates or finalising requirements.

Sprint planning.

Use the sprint planning sessions to assess your stories. When discussing each user story, add a fixed agenda item to address the potential blockages. Assess each requirement, encourage team to visualise the completion of those requirements, the deployment of the features and the testing. Ask everyone to look at the story from the lens of what could go wrong. This approach works wonders for uncovering things like missing permissions to environments, software and tools the team members might require later or even misunderstanding of the requirements.

Daily standups.

During your daily standups, visually highlight the blockers, for example draw a parking lot in red, and give them the 'priority seats in the front'. Start your standups with discussing actions around blockers. Once that is complete, move to the more traditional person-to-person format. To maintain a sense of importance and to keep things flowing, use the appropriate language and foster a culture of urgency.


If you find yourself and your team struggling to identify meaningful improvements in your retrospectives, blockers always make a good case study. Focus on obstacles you experienced during the sprint and how the team managed to overcome them. Discuss what could be done in the future to handle them better and, of course, how to avoid them altogether.

What to consider when go proactive.

In the proactive approach, try to anticipate complexities and potential challenges. Take into consideration the additional processes or structures in place in certain industries, such as the finance or government sector. Factor in the need for solution reviews within the appropriate project management office, architectural and/or legal forums. When working with customer-facing technology, such as web or application content, consider marketing reviews and user experience as important processes to work through. 

The final consideration is, of course, the development itself. The required hardware and software may need to go through the procurement process. When it comes to environments set-up, allocate time to build infrastructure and look into the additional skill sets, like DevOps, you might require. Most of the problems could be prevented with the right amount of planning and proactive management.

proactive approach in blocker managements 2

I'm my experience, actions assigned to multiple people often cause confusions around roles and responsibilities. Scrum theory eliminates this confusion by making the scrum master in charge of blockers management. That is not to say that he will solve the problems himself; he may not possess the technical skills or authority to do so. The scrum master should use the support of the team to remove blockers while owning their management and tracking. But the most important thing is to shift from a reactive mindset to a proactive one.

Good luck with beating the blockers!

We’d love to hear your opinion on this post