Impediments in Scrum: How to Spot, Log and Remove What Blocks Your Team

Impediments in Scrum: How to Spot, Log, and Remove What Blocks Your Team.png

Impediments in Scrum: How to Spot, Log, and Remove What Blocks Your Team

Have you ever been on a sprint that was going along great until a small problem stopped the work in its tracks? Maybe a developer couldn’t get into a test environment, an approval was taking ages, or another team didn’t deliver what yours needed.

These are examples of obstacles in Scrum. They're impediments that block a Scrum Team’s progress or make it harder to achieve the Sprint Goal.

Some blockages are easy to get out of. Some are about decisions, people, or processes outside of the team's control. The Scrum Master helps the team to identify these impediments, to get the right help, and to drive for a resolution.Removing impediments is one of the core Scrum Master roles and responsibilities.

Impediment logs also help everyone know what is blocking progress, what is being done about it and whether the issue is resolved.

Key Highlights of Impediments in Scrum

• Impediments in Scrum are obstacles that prevent or slow down a team's progress towards its sprint goal.
• The main types of impediments in Scrum include technical problems, organizational barriers, communication issues, and external dependencies.
• Scrum impediments examples include unavailable testing environments, delayed approvals, unclear requirements, and dependencies on other teams.
• An impediment log helps teams record blockers, understand their impact, and keep track of the actions needed to resolve them.
• The Scrum Master helps remove impediments by facilitating conversations, connecting people, and addressing barriers beyond the team's control.
• Good impediment management isn't about making the Scrum Master responsible for every problem. It's about helping the team resolve issues and become better at handling them independently.

Introduction

Imagine, it's day three of a two-week sprint. A developer has completed a feature and is ready to test it, but the test environment is broken. Someone raises a ticket with the IT team. A few hours pass, then a day. The environment is still down, and the developer can’t do the work.

Meanwhile, the rest of the team is trying to work out if they can continue with other tasks or if the delay will affect the Sprint Goal.

The frustrating part? The issue is not in the code, the skills of the developer, or the planning of the team. Something is getting in the way that is not part of the real development work.

That’s why impediments in Scrum deserve attention.

There are always challenges for every team from time to time. A missing decision, a confusing requirement, an unavailable colleague, or a long approval process can throw a well-planned sprint off track. The problem is when these issues are ignored, left unresolved, or keep coming back sprint after sprint.

Spotting Scrum impediments means you have to be able to see these situations early and deal with them. In this guide we’ll cover the different types of impediments in Scrum, explore practical Scrum impediment examples, and explain how to resolve impediments in Scrum without making the Scrum Master the one who has to solve everything.

What Counts as an Impediment in Scrum?

An impediment is anything that blocks the Scrum Team from moving forward. It can stop a developer from finishing a task, cause collaboration issues, or prevent the team from progressing to the sprint goal.

A developer needs API credentials for testing a new feature. The code is written, the developer knows what to do next, and there is no technical problem with the implementation. The only issue is that the credentials haven't arrived.

The developer can't move forward until someone resolves that access problem. That's an impediment.

Of course, not every difficult task is an impediment. Some problems are simply part of software development. For instance, a complicated piece of code might take longer than expected. But if the team has the skills and resources to work through it, then you don’t need to treat the challenge as a separate blocker.

That changes when the team needs something it cannot provide for itself, whether it’s specialist support, access to a system, a decision from a stakeholder, or a change to an organizational process.

The Scrum team works together towards the sprint goal, while the Scrum Master helps improve the team's effectiveness and addresses impediments that get in the way of progress.

It is also useful to know the difference between an impediment and a risk. A risk is something that might cause trouble later. An impediment is already affecting the work.

For example, a team may be worried that a supplier may deliver a part late. That point it is a gamble. If the delivery date passes and the team cannot continue without that component, the problem becomes an active impediment.

Recognizing this difference helps teams respond appropriately instead of treating everything as an emergency.

Types of Impediments

Impediments can come from almost anywhere. Sometimes the problem is technical. Sometimes it's buried in an approval process or comes down to two people having different expectations.

Understanding where an impediment comes from makes it easier to work out who can help resolve it.

Technical Impediments

Technical impediments are the problems that get in the way of actually building, testing, or delivering a product.

These may include:

• A development or test environment that simply stops working.
• Missing API credentials or system permissions.
• Integration issues of two applications.

Imagine a team working on a payment feature. The code is done by the developers, but the testing environment has been down since the afternoon before. The feature is not confirmed to work properly, and the task is left unfinished.

The Scrum Master might contact the infrastructure team to help get the environment restored. While that's happening, the developers can look at whether there is other useful work they can continue safely.

Notice that the Scrum Master doesn't have to understand every line of code or fix the environment personally. Their job is to help the right people connect and remove the obstacle that's preventing progress.

Organizational Impediments

Sometimes the team is doing all they can, but the organization itself is making it difficult to make progress.

Organizational barriers are often caused by processes, policies, competing priorities or decisions outside the team’s control.

For example,

• A routine change needs sign off from several different managers.
• A specialist is shared across multiple projects and is rarely available.
• Purchase of essential tools is delayed due to procurement

Imagine a team is ready to release a feature they've finished. But the release needs to be signed off by three departments, and one approval has been pending for days.

Developers did their part, but the feature still can't reach users.

The Scrum Master can work with the relevant stakeholders to understand the cause of the delay and to see if the process can be improved.

If the same approval issue is happening sprint after sprint, running after approvals every time is not a sustainable solution. The team needs to look at why the process keeps causing delays in the first place.

People and Communication Impediments

Not every impediment comes from a broken system or a slow process. Sometimes, people simply aren't working with the same understanding of what needs to happen.

Communication-related impediments can be particularly tricky because they aren't always obvious until something goes wrong.

Typical examples include:

• Team members don't know who is responsible for a decision.
• Developers have different views on acceptance criteria.
• A stakeholder is too slow to answer a critical question.

A designer may think the checkout page should work one way, but the developer creating it interprets the requirement differently. Both get on with their work, only to discover the mismatch during testing.

Now there's rework that could probably have been avoided with a short conversation earlier in the sprint.

The Scrum Master can help to get the right people in the room, promote an open discussion and help the team to have a shared understanding of the problem. The product owner may also need to clarify desired behaviors or product priorities.

The important thing is to make it easy to speak up. When team members have the psychological safety to ask questions and raise concerns, problems surface earlier.

External Dependencies

Sometimes, a team can't move forward because it's waiting for someone outside the team.

Such dependencies are common when scaling Scrum across multiple teams working on the same product.

For instance,

• Waiting for another team to release an API.
• Neding input from a legal or compliance professional.
• A supplier isn't able to deliver goods on time.

Consider a team that is building a mobile application that depends on an authentication service being developed elsewhere. The mobile developers are ready to integrate theirs, but the service is not ready yet.

Instead of everyone sitting around idle, teams could agree on an interface contract or use a mock service to keep working while the real service is being built.

Sometimes that kind of workaround is good enough to keep things moving.” In other situations, the Scrum Master may need to help coordinate the teams or escalate the delay to someone who can make a decision.

The important thing is to make the dependency visible early and avoid waiting until the end of the sprint to discover how much it has affected progress.

Impediment Examples From Real Sprints

It's easier to understand Scrum impediment examples when you look at what they actually mean for a team trying to get work done.

Take the delayed API example. Writing "waiting for API" in a task tracker doesn't tell anyone what should happen next. The team still needs to know who can provide an update, whether there is a workaround, and how the delay affects the sprint goal.

That’s the difference between logging an impediment and managing an impediment.

The same is true for other impediments in Scrum. Find the problem, know what it’s affecting, agree on the next step, and follow through until the team can move forward.

How Impediments Surface in Scrum Events

Scrum events give the team regular opportunities to discuss progress and work out what needs attention. However, team members shouldn't have to wait for a meeting to raise an urgent blocker.

If something is getting in the way of their work, they can bring it up as soon as they notice it.

Sprint Planning

Sprint Planning is a good opportunity to identify obstacles before work begins.

While the team is discussing the sprint goal and what work it can take on, developers might spot a task that depends on an external team, input from a specialist, or a decision that has not been made yet.

For example, if a feature requires approval from another department, the team can discuss the dependency in planning and figure out how to address it.

Not every problem can be predicted, of course. But finding known constraints earlier gives the team more options than finding them halfway through the sprint.

Daily Scrum

The daily Scrum helps developers inspect progress towards the sprint goal and adapt their plan for the day.

A developer might explain that testing has stopped because a required service is unavailable. The team can discuss what needs to happen next and who might be able to help.

The Daily Scrum isn't meant to become a round-robin status report, and it's certainly not the only place where impediments can be raised. Team members can discuss blockers before or after the event, or through their usual communication channels.

If a problem needs immediate attention, there's no reason to wait until tomorrow's meeting.

Sprint Review

The Sprint Review is an opportunity for the Scrum Team and stakeholders to inspect the results of the sprint and adapt the next steps.

Sometimes these conversations highlight recurring obstacles. Perhaps the team couldn’t validate a critical assumption because of late feedback from customers, or a feature was blocked because of a dependency on another department.

Discussing these issues in public lets stakeholders learn what influenced the outcome and where changes could make future work simpler.

Sprint Retrospective

The Sprint Retrospective is particularly useful when the same impediments keep showing up.

Instead of simply discussing what went wrong, the team can look for patterns and decide what to change.

For example, if developers have struggled with access requests for three consecutive sprints, the team might agree to request access earlier or work with the relevant department to simplify the process.

This is where a frustrating experience can become a useful lesson. The aim isn't to spend the meeting assigning blame. It's to leave with a practical improvement the team can try.

Building and Using an Impediment Log

When a blocker takes more than a quick conversation to resolve, it's easy for follow-ups to get lost. Someone sends a message, another person promises to investigate, and a few days later nobody is quite sure where things stand.

An impediment log helps prevent that.

It’s a shared account of the impediments (issues) that impact the team, how they impact the team, and what’s being done to fix them. The Scrum Guide does not require teams to maintain one, but it can be useful when there are a lot of issues to track or the resolution involves people outside the team.

Here's what a simple impediment log might contain:

Teams can add details such as the date the impediment was raised, its priority, the next action, and a follow-up date. There's no need to make the log complicated. It should contain enough information to help people act, not so much that maintaining it becomes a task in itself.

How to Maintain the Log Without Creating Extra Work

Start with a tool the team is already using. You usually just need a shared document, a project board, or an existing project management platform.

If someone raises a blocker, write down what’s going on and how it’s affecting progress. Decide what the next step is and who will coordinate it.

That person doesn't have to solve the problem alone. For instance, the Scrum Master can contact the infrastructure team while the developer works on the technical issue.

Regularly check on any open impediments, particularly those that may affect the sprint goal. Capture any useful learning and update the issue status to resolved.

It’s also worth seeking patterns. If the same type of blocker keeps appearing, bring it up during the sprint retrospective and discuss what could prevent it from happening again.

The log should make it easier to resolve problems. If it becomes another reporting exercise that nobody finds useful, simplify it.

How to Remove Impediments Step by Step

Knowing how to remove impediments in Scrum isn't about following a complicated process. It's about making sure that a problem doesn't sit unnoticed while the team waits for someone else to act.

Here's a practical approach.

Step 1: Identify and Describe the Problem

Start by finding out what's actually stopping progress.

Saying "Development is blocked" doesn't tell you very much.

“The team cannot test the payment integration because sandbox credentials haven't been issued," on the other hand, gives everyone a clearer picture.

Ask the person affected to explain what they were trying to do, what happened, and what they need to continue.

Step 2: Understand How Much It Matters

Not every impediment needs the same level of attention.

A small delay on one task might be manageable if the team has other useful work to do. A blocker that prevents several developers from progressing or threatens the sprint goal needs a more urgent response.

Look at the actual impact before deciding what to tackle first.

Step 3: Find the Right Person to Involve

Once the team understands the problem, work out who can help.

A developer might resolve a configuration issue. The product owner might clarify a requirement. An infrastructure specialist might need to restore a service, while a manager might need to change a process that's delaying access.

Getting the right people involved early is often more effective than sending repeated follow-up messages to someone who can't actually solve the problem.

Step 4: Agree on What Happens Next

A useful conversation should end with a clear next step.

For example, a developer might investigate a failed integration while the Scrum Master contacts the team responsible for the unavailable service.

Agree on who will coordinate the response and when to check in again. If there's a safe workaround, consider whether the team can use it to keep other work moving.

Step 5: Escalate When the Team Needs Help

Some obstacles can't be resolved by the team alone. If progress depends on a decision, resource, or authority the team doesn't have, involve someone who can help.

When escalating, explain what's happening, why it matters, what the team has already tried, and what support it needs.

Escalation isn't an admission of failure. Sometimes, the problem sits within a process or structure that the team has no power to change.

Step 6: Check That the Problem Is Actually Resolved

An update saying "fixed" doesn't always mean the team can continue.

If a testing environment has been restored, for instance, the developers still need to verify that their tests can run. If a delayed decision has arrived, they may need to revisit the work that was waiting on it.

Once the team can move forward, close the impediment and consider whether there's anything to learn from the experience.

If the same issue is likely to happen again, look for a longer-term fix rather than relying on the same workaround every sprint.

When to Escalate and to Whom

Knowing when to ask for help is part of handling impediments well. If the team has tried reasonable solutions but still can't move forward, escalating the issue may be the quickest way to get things unstuck.

The right person depends on what's causing the problem.

When you escalate, be specific about what you need.

Saying "the API is late" doesn't give stakeholders much to work with. Explaining that the authentication API is three days behind schedule, integration testing cannot proceed, and the team needs either a revised delivery estimate or an agreed testing interface makes the problem much easier to act on.

It's also important to keep escalation proportionate. A minor technical question doesn't need to reach senior leadership if the team can resolve it directly.

The point is to get the right support without creating unnecessary layers of communication.

The Scrum Master's Role: Facilitate, Not Fix

The Scrum Master plays a key role in helping the team to work through impediments. But there’s a difference between helping people solve problems and being the person everyone turns to to solve problems.

The Scrum Master is accountable for enacting Scrum as defined in the Scrum Guide and for the effectiveness of the Scrum Team. That means helping the team get past obstacles and get better at how it works.

A Scrum Master as a servant leader focuses on helping people become more effective rather than simply telling them what to do.

In practice that might be helping developers work through a blocker, bringing the right stakeholders in a conversation, or working with management to resolve a policy that’s hindering multiple teams.

The Scrum Master may also assist the team to identify recurring problems, make unresolved impediments visible, and use the Sprint Retrospective to agree on improvements.

But if the Scrum Master takes up every obstacle, the team can slowly become dependent on him/her. Even simple problems start to wait for one person to act on them.

It’s better to ask questions like “What’s in the way?” or “What would help you move forward?”

Some situations call for direct action. An organizational impediment may require the Scrum Master to work with senior stakeholders or to facilitate a difficult conversation. The point is not to avoid doing something. We want to help solve the problem but still allow the team to own their work.”

Professionals looking to strengthen these skills can explore Certified Scrum Master training or Advanced Certified Scrum Master training to learn more about facilitation, team effectiveness, and impediment management.

Common Mistakes When Handling Impediments

Even teams that understand impediments can fall into habits that make them harder to resolve. Here are some common mistakes to avoid.

1. Waiting until the Daily Scrum to mention a blocker. If a developer discovers an urgent problem but waits until the next morning to raise it, the team loses valuable time. Encourage people to speak up as soon as an impediment affects their work.

2. Recording problems and then forgetting about them. An impediment log won't help if nobody follows up. Significant blockers need a clear next action and regular attention until they're resolved.

3. Escalating every little problem. Not every issue requires management intervention. Let the team solve what it can, and ask for help when the obstacle genuinely exceeds its control.

4. Expecting the Scrum Master to fix everything. This creates a bottleneck and weakens self-management. The Scrum Master should help coordinate resolution, while the people best placed to act contribute to solving the problem.

5. Fixing the symptom instead of the cause. Restarting a failing testing environment might get work moving today, but repeated failures could point to a deeper infrastructure problem. When an issue keeps returning, investigate why.

6. Turning blocker discussions into blame sessions. If people expect criticism whenever they raise a problem, they may stop speaking up. Focus on what happened, what got in the way, and what could be improved.

7. Ignoring recurring patterns. If the same dependency blocks the team every sprint, treating each incident as a one-off means missing the opportunity to fix the underlying process.

Avoiding these mistakes makes impediment management more useful and less bureaucratic. It also helps the team spend less time dealing with the same frustrations and more time delivering valuable work.

Conclusion

Every Scrum Team runs into obstacles. A system stops working, a decision takes longer than expected, or a dependency falls behind schedule. That's part of working in a complex environment.

What matters is what comes after.

Impediments are easier to manage when they're raised early, discussed openly and followed through to resolution. A list of impediments can help the team to keep track of the issues that are outstanding. Scrum events are opportunities to understand recurring problems and to agree on improvements.

Some of the hurdles can be overcome by the team. Some need help from stakeholders or changes in the way the organization works. When the difference is known, the team can respond without wasting time on repeated workarounds or unnecessary escalation.

It's important to remember that the Scrum Master does not have to be the person who solves everything. They are there to help the team work through obstacles, give support they need, and learn to be more effective in dealing with challenges on their own.

Sprints don't need to be perfect. They're built so that a team can recognize when something is wrong, work out what to do about it, and keep moving towards delivering value.