Removing blockers: a practical guide for Scrum Masters
A feature is ready to test, but nobody can access the test environment. The request has been sent. The team is waiting. At the next Daily Scrum, the same problem comes up again.
For a Scrum Master, this is a moment to turn a vague delay into a clear next action. That might mean helping the team investigate, bringing the right people together or getting an organisational decision made.
This guide offers five practical steps for removing blockers while supporting the team’s ability to manage its own work. The delayed access request is an illustrative example throughout, not a reported client case.
What counts as a blocker?
An impediment is something that hinders the team’s progress. A blocker usually describes a more immediate obstacle preventing a particular piece of work from moving forward. Teams use these terms differently, so agree what they mean in your context.
- Missing access: the team cannot test a feature in the required environment.
- An unanswered decision: conflicting requirements leave the team unsure what behaviour to build.
- An external dependency: another team must provide an interface before integration can proceed.
Normal technical difficulty can often be worked through by the Developers. Ask what support would help rather than assuming every difficult task needs escalation.
The Scrum Guide connects the Scrum Master’s role with removing impediments and coaching self-management. In practice, that means helping the problem get resolved while keeping the team involved in the decisions.
Five steps to move work forward
1. Understand the actual problem
Purpose: Make the obstacle specific enough to act on.
“Testing is blocked” describes a symptom. Find out which environment is needed, who lacks access, what request has been raised and what is preventing it from progressing.
- What exactly cannot move forward?
- What has already been tried, and what happened?
- How does the delay affect the Sprint Goal, the objective the team is working towards?
2. Choose the right kind of support
Purpose: Match your intervention to what the team needs.
Ask whether the team has the skills and authority to resolve the issue. Offer coaching where a next step is unclear, facilitate where people need to collaborate, and involve an appropriate decision-maker where authority sits outside the team.
Help identify the next action and support the team in taking it.
Bring the right people together to reach a decision.
Ask someone with the relevant authority for a specific decision.
For the access example, help identify an authorised alternate approver and make the impact clear. Agree when to review the request. Keep the approval process intact and confirm access actually works.
3. Make the next action visible
Purpose: Turn a reported problem into an action someone can follow through.
Keep a lightweight record alongside the affected work. It should explain the impact, the next action, who has agreed to take it and when the team will check progress. The person taking an action is not necessarily the person with authority to approve it.
| Blocker | Two Developers cannot access the test environment. |
|---|---|
| Impact | Checkout testing cannot begin; the Sprint Goal is at risk. |
| Next action | Ask the platform team to identify an authorised alternate approver. |
| Action owner | Scrum Master, as agreed with the team. |
| Review point | Today at 2pm; check for a decision and agree the next action. |
A blocker record is an optional working practice, not an additional Scrum artefact. Link it to the affected item and keep it current.
4. Help the team adapt
Purpose: Respond to the impact while the obstacle is being resolved.
Do not let an unresolved request become the team’s entire plan. The Developers can consider useful work that supports the Sprint Goal, such as preparing test cases or completing independent checks. Be clear about what those alternatives can and cannot validate.
Where scope needs to change, the Developers collaborate with the Product Owner while protecting the Sprint Goal. The Scrum Guide describes this adaptation; it does not give the Scrum Master authority to assign replacement tasks.
5. Reduce the chance of recurrence
Purpose: Improve the conditions that caused the delay.
Once access works, look beyond closing the request. Why was there no alternate approver? Was the dependency discovered too late? Has the same issue affected other work?
-
1. Identify
Find the recurring cause. -
2. Act
Agree one improvement. -
3. Review
Check what changed. -
4. Adapt
Keep or revise the approach.
For example, agree an alternate approval route with the platform team and check environment needs earlier. At the next relevant request, review whether the change helped. A retrospective can support that conversation, but an urgent improvement need not wait for the next meeting.
Try this with one current blocker
Choose one obstacle affecting your team. Write a single sentence explaining what cannot progress and why it matters. Then agree the next action, who will take it and a review point.
Ask yourself: “What support would help the team move this forward, and what needs to change so it is less likely to happen again?”
A useful intervention leaves the team clearer about what happens next. Over time, it should also make the working environment easier to navigate, with fewer repeated delays and less dependence on one person to chase everything.
Framework reference: The Scrum Guide, November 2020, by Ken Schwaber and Jeff Sutherland. The decision aid, blocker record and access scenario are practical illustrations, not prescribed Scrum artefacts or reported project results.
You May Also Like
How to measure whether an AI feature is actually helping users
Boost Your Product Management Game with the Eisenhower Matrix: A Simple Strategy to Prioritize Like a Pro
