Impediments: finding them, logging them, removing them

"We're waiting on access." It is said in the Daily Scrum on Tuesday, and again on Wednesday, and on Thursday it is simply part of the furniture. Nobody has been negligent. Everyone assumed someone else was dealing with it. An impediment log exists to stop that sentence being said three days running.

What counts

The SBOK® Guide defines an impediment as any hindrance or hurdle that reduces the productivity of the Scrum Team. It says impediments must be identified, resolved and removed if the team is to keep working effectively, and that failing to do so can be very costly. They may be internal, such as an inefficient workflow or poor communication, or external, with software licence problems and unnecessary documentation requirements as its examples.

The Scrum Guide does not define the word, but it uses it in the same way. The Daily Scrum improves communication and identifies impediments, and the Scrum Master serves the team by causing the removal of impediments to its progress. The phrase "causing the removal" is deliberate. The Scrum Master does not have to fix every impediment personally. They have to make sure it gets fixed.

A practical test: is the team unable to resolve it by itself? A Developer who needs to ask a colleague a question has a conversation, not an impediment. A Developer who cannot proceed without a decision, an access right, a purchase or a change from another department has an impediment.

Where they come from

Impediments cluster into a few families.

• Access and environments. No test environment, an expired certificate, a missing account.
• Decisions. An answer only the Product Owner or a stakeholder can give, and it has not come.
• Dependencies. Another team or a vendor holds something the work needs. See stories, tasks and dependencies.
• Process and interruptions. Meetings outside Scrum, requests that bypass the Product Owner, unnecessary approvals.
• Skills and knowledge. Only one person can do a task, or nobody can.
• The team itself. A recurring friction, unclear working agreements, low morale.

The SBOK points out that the transparency inherent in Scrum makes impediments quick to spot, which is the point of the board and the daily meeting.

How to find them early

• At the Daily Scrum. The SBOK's version of the meeting asks about impediments directly. The Scrum Guide's version leaves the format to the Developers, but says it identifies impediments. Either way, listen for the word "waiting" or "still".
• On the board. A task that has not moved for two days is a prompt to ask why.
• In the Retrospective. The slower, structural impediments appear here. See the Retrospective.
• At the Sprint Review. The SBOK says impediments should be discussed in the Sprint Review as appropriate, because stakeholders are often part of the cause.
• By watching. A Scrum Master who attends the events and listens will hear problems before they are named.

The log

The SBOK has the Scrum Master record impediments formally in an impediment log, to be discussed at the Daily Standup and Sprint Review meetings as appropriate. The Scrum Guide does not name a log, but it asks for transparency, and a visible list is the simplest form of it.

A log can be a section of the board, a shared document or a column in a tool. What matters is what it contains:

Two habits keep it alive. Review it at every Daily Scrum, briefly, and review its age. And close items explicitly: "resolved on Thursday, by the platform team" is a small piece of evidence that raising problems works.

Who removes it

Under the Guide, the Scrum Master is accountable for causing the removal. In practice there are three routes.

1. The team solves it. Some impediments feel external and are not. A short conversation or a small change in how the team works is enough.
2. The Scrum Master solves it. Chasing an approval, arranging access, having a word with someone who is interrupting the team.
3. It is escalated. When the cause sits with management, another department or a vendor, the Scrum Master takes it up the line. The SBOK says that when required, the Scrum Master can escalate external issues and impediments to management for resolution or removal.

A useful rule is to ask for the decision, not for sympathy. "We need a test environment by Thursday or the payment story will not make the Sprint" can be answered. "We are having environment problems" cannot.

A worked example

An invented case. On day two, a Developer reports that the payment provider's test account has not been approved. The Scrum Master adds it to the log, names itself as owner, and records the cost: the payment story depends on it.

• Day two. The Scrum Master contacts the person who can approve and asks for a date.
• Day three. No reply. The Daily Scrum notes the item has not moved, and the team agrees to build against a stub in the meantime.
• Day four. The Scrum Master escalates to the sponsor's office with a single sentence about the date at risk.
• Day five. The account is approved. The log records it as resolved, and the team swaps the stub for the real thing.

Two things made the difference: the item was written down with an owner, and the team found a workaround that kept the goal alive while the impediment was being removed.

Common mistakes

• Treating every difficulty as an impediment. A log of forty items buries the three that matter.
• No owner. An item everyone knows about is not being handled.
• A log nobody reads. If it is not visited at the Daily Scrum, it is a graveyard.
• The Scrum Master hides problems from the stakeholders. Transparency applies upward too.
• Escalating with no ask. A report without a request gives the manager nothing to do.
• Working around the same blocker repeatedly. A workaround that becomes permanent is a debt. The Retrospective should ask why the cause was never removed.

The Agile Manifesto principle that the team regularly reflects on how to become more effective, then tunes and adjusts its behaviour, is the other half of dealing with impediments: fix this one, then ask what produced it.

How to practise it

In the simulator, impediments surface on the board and at the daily standup, and you decide whether to clear them, log them and carry on, or leave them to the team. Each choice has consequences that carry forward into later Sprints.