How do blockers and impediments differ, and when do you escalate?

WHAT THIS TESTS: This question tests whether you understand flow mechanics at two different altitudes. A senior Scrum practitioner knows that not every obstacle deserves the same response. The interviewer wants to see if you can diagnose whether a problem is a tactical pause that the team owns or a systemic drag that requires organizational leverage, and whether you have an actual protocol for the latter instead of just hoping someone else notices.

A GOOD ANSWER COVERS: First, the definitions. A blocker is a red-light issue that halts progress on a specific task for a specific person, like a broken dev environment, a missing API contract, or a critical bug that prevents testing. It is immediate and local. An impediment is broader; it is any condition that slows the whole team even if work still moves forward, such as unclear requirements, chronic scope creep, poor tooling, or leadership indecision. It is chronic and systemic. Second, the handling protocol. Blockers should be surfaced immediately in the Daily Scrum, made visible on the board, and attacked by swarming or re-sequencing work; the Scrum Master steps in only when the issue is outside the team's direct control. Impediments need intentional reflection space, usually retrospectives, because teams tolerate them for weeks or months. The Scrum Master should create and maintain an impediment backlog, prioritize it by impact on velocity or morale, and treat serious items like mini-change initiatives. Third, escalation. When the team cannot resolve an impediment alone, the Scrum Master gathers data, for example three Sprints of velocity decline or hours lost to Wi-Fi outages, frames the business cost, proposes one or two concrete remedies, and takes it to the relevant leadership forum rather than dumping the problem upward.

COMMON WRONG ANSWERS: The biggest red flag is conflating the two categories, saying something like they are basically the same just different severity. Another mistake is claiming that the Scrum Master removes all blockers personally; the team should swarm first. A dangerous pattern is escalating every blocker to management, which trains leadership to ignore your pings. Conversely, saying you would just add impediments to the product backlog shows you do not understand that impediments are process or environment problems, not product work.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a recurring blocker that appears every Sprint, which is the classic bridge to recognizing it has become an impediment. They may also ask what you do if leadership ignores your escalation, or how you measure the cost of an impediment in hard numbers.

ONE CONCRETE EXAMPLE: Suppose the team loses roughly two hours every day to flaky VPN access in the remote office. It does not stop a single task completely, so it is an impediment, not a blocker. You track the time loss for two Sprints, calculate that it costs about twenty percent of a full-time engineer per month, and present that metric to IT leadership along with two options, a corporate VPN upgrade or dedicated hardware. You add the item to the impediment backlog, set a resolution target, and review progress in each retrospective until it is closed.

Source: artisanagility.com