Blocker vs Impediment (It’s Not Just Semantics)

Don’t allow your minimal progress lugging around a ball and chain to convince you there is no impediment. Complacency is the enemy of progress.

Defining Blocker and Impediment

Commonly the terms impediment and blocker are used interchangeably. Although they are similar, they are not precisely the same.

Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips defines an impediment as:

“an event that impedes any of the developers from working to their anticipated sprint capacity.”

-Ilan Goldstein

On the other hand, a blocker refers to a situation where work has completely halted on an item and cannot progress without eliminating the issue.

An impediment slows progress, but a blocker halts progress.

Blocker vs Impediment

All blockers are impediments, but not all impediments are blockers. When a work item is blocked, this will impede developers from working to their anticipated Sprint capacity. However, the Development Team can make some progress on an impeded work item.

For example, having no requirements is a blocker. There isn’t anything we can do if we don’t have any indication of what we need to build. Having vague requirements may only be an impediment. We can progress with the building of a button without knowing the exact words that need to be on the button.

Technical debt is also an example of an impediment. We can still make progress, but we’re slowed by having to work around inefficient code or inferior architecture. If we took the time to resolve the technical debt, all future work would be faster - not just this single work item.

Scrum Guide Terminology

The Scrum Guide does not refer to the term “blocker” and only refers to the word “impediment.”

According to the Scrum Guide, the Scrum Master is responsible for causing the removal of impediments.

“The Scrum Master serves the Scrum Team in several ways, including:

• […]
• Causing the removal of impediments to the Scrum Team’s progress”

-Scrum Guide

At first, this phrasing seemed a bit awkward, but I grew to appreciate the distinction after some reflection. It will not always be within the Scrum Master’s power to remove an impediment. Still, they can find the person who does possess the authority, communicate the need of the Scrum Team, and follow through to ensure the eventual removal of the obstacle.

The 7 Habits of Highly Effective People differentiates between one’s circles of concern and influence. The circle of concern encompasses all the things we concern ourselves with but cannot control, and the matters that we can control fall within our circle of influence.

New Scrum Masters may feel unsuccessful in their role when the Development Team escalates issues to them that are in the circle of concern but not in their sphere of control.

To be successful in their position, they will learn to extend and leverage their circle of influence.

The Scrum Team needs to identify the impediment before a Scrum Master can do anything to resolve it.

The Daily Scrum is an excellent opportunity for the Development Team to surface these issues.

“Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.”

-Scrum Guide

Although the Scrum Master is responsible for causing the removal of impediments, I think it’s important to recognize that the Development Team or Product Owner can and should resolve any items under their control. Assigning everything to the Scrum Master for resolution sets them up to become a bottleneck to impediment removal.

The Scrum Master can coach the team, provide options, and help point out the elephant in the room, but they don’t have to be the ones to actively resolve every issue.

Why You Should Care

Given that it’s become standard to see these terms used interchangeably, does it matter which word we use? Is the selection of one designation over the other just a pedantic exercise?

Blockers are generally apparent to the team. When work comes to a complete stop, ignoring that situation is challenging. Impediments, on the other hand, can linger without notice. There is a false sense of security that comes with being able to make some progress. We want to believe that as long as we’re making some movement in the right direction, we’re probably fine and don’t need any help. Given that impediments affect more than just one user story, this can be a dangerous dysfunction for a team to exhibit.

Asking if the team has “impediments” instead of “blockers” might be the paradigm shift that the team needs to recognize systemic issues that they’ve previously ignored.

Being clear about which impediments are blockers can also help the Scrum Master prioritize the items on their list. It might be that the thing that has come to a complete stop needs the most attention. Alternatively, it might be more beneficial to remove the impediment blocking more than one work item.

Having all the information needed to appropriately prioritize the removal of impediments and blockers is the key.

Works Consulted

• Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips
• The 7 Habits of Highly Effective People
• Scrum Guide
• Blocked or Impeded?

TLDR

Using the term blocker and impediment interchangeably can lead to the Development Team incorrectly assuming they only need to report blockers. If a developer struggles to complete a work item, she should openly discuss what work item so the Scrum Team can help efficiently resolve the obstacle. If we only highlight blockers, we may inadvertently miss an opportunity to remove an anchor from the team, preventing them from reaching their true potential.