Impediment List

(Impediment Backlog)

...the team is trying to make progress on the Value Stream. Something has come up which hinders progress. The affected people do not handle the problem immediately, but it must be handled to remove constraints to progress.

✥      ✥      ✥

Team members often run into things that impede their progress. Fixing them at the moment may not be possible, practical, and/or in the best interest of the organization or team. For example, internal or external events can impact a development team’s work on the Product Roadmap, causing it to slow down. It may be advisable to fix a problem immediately, but that takes time away from making progress on the Sprint Backlog. (See Someone Always Makes Progress.)

On the other hand, if you don’t resolve an impediment immediately, it can shift from being an acute problem to a chronic problem; something you just live with and kind of ignore.

An impediment is often something that prevents the Development Team from doing its work, but it may also be anything that prevents it from improving its performance. For example, team interaction issues can get in the way of making progress. Slow or outdated equipment may prevent the team from working at its best.

Not all impediments can be solved by the Development Team or even the Scrum Team. For example, an extremely serious impediment such as “an act of God” may require a Scrum Emergency Procedure.


Make impediments visible. A common way to do this is with an Impediment List. The Impediment List is owned by the ScrumMaster. Create an impediment backlog, a list of ordered blockers for the Scrum Team, ordered by relative severity and value. Make the issues visible; raise them up to the right level and people in the organization.

The Impediment List is owned by the ScrumMaster. This may include escalating impediments to the person who can fix it, such as the Product Owner or individuals outside the Scrum Team, such as the IT support group or the HR team.

Any Scrum Team member may add an impediment to the list to make it visible. This presupposes that the Scrum Team is a Community of Trust, because some impediments may be difficult to raise, such as personal ones relating to health or family situation. A Sprint Retrospective is a good opportunity to raise such issues. A team member should always be able to confide such impediments with the ScrumMaster, who may choose to work the issue discretely, in the interest of preserving the dignity of the individual.

Items on the Impediment List may be disposed of in one of several ways. These items may be resolved by the Scrum Team itself or by others outside the Scrum Team. ScrumMasters may themselves personally attend to issues that would otherwise be a distraction for the team, and which do not require the team's expertise to resolve. Or work may be added to the Product Backlog to resolve the impediment.

✥      ✥      ✥

The Impediment List is a manifestation of Kaizen Mind. An empty Impediment List means that you aren’t looking hard enough for ways to improve. (“No problem is a problem.”) On the other hand, impediments must be resolved in a timely manner; otherwise you are not improving. Impediments must not get stale on the list. The Scrum Team reviews the Impediment List during every Sprint Retrospective.

True story: A team was complaining about their manager who wasn't removing impediments for them. I asked if the manager knew what the impediments were and they said they assumed he did. I had the team write the impediments on fluorescent Post-It® notes with the word “Block” in bold at the top, and took them to the manager. As he wasn't there I plastered them around his monitor so he couldn't miss them. Half an hour later he called out looking for me. He came up and asked if these were blockers from the team. I responded: Yes, and he smiled saying it was great as he now knew what he needed to be working on.

Picture from: Damian Dovarganes