1. Home
  2. Smartpedia
  3. Impediment

What is an Impediment?

Table of Contents: DefinitionThe Tasks of the Scrum MasterVisualisationManagementExamplesChallengesTips and TricksDownloadNotes

Smartpedia: Impediments are problems that hinder teams or team members in their tasks. In the sense of self-management the problems should be solved by the team members on their own.

Impediment Definition

An Impediment is a handicap – this is how the dictionary explains it. Or an obstacle, an impairment, or an aggravation. In Scrum, and consequently in agile project management and the development of software, products and services, an impediment is understood as a disturbance that occurs during work and restricts teams or individual team members in the completion of activities. This impediment is a factor that can endanger the achievement of agreed (sprint) goals.

The Scrum Guide 2020 describes that the Scrum Master supports the Scrum Team in eliminating the impediment. How this is done depends on the context and is not described in detail. This means that the current issue also dispenses with a reference to explicitly ask for obstacles on the way to the Sprint Goal in the course of the Daily Scrum. This hint could still be found in the 2017 version.

Impediment Board - the visualisation of obstacles

The Tasks of the Scrum Master in the Context of Impediments

The Scrum Master is responsible for the compliance with the elements and rules of Scrum and the implementation in the company. He ensures that events are carried out and protects the team from unauthorised interference during the sprint. Depending on the agreement within an organisation, his task could be to document impediments, remove them if necessary and involve the company management if required. Since the Scrum Master tries to support the development team on the way to self-management, it is important in real life to clarify some points clearly:

  • Is it an impediment and could the team remove the obstacle itself?
  • Is it necessary to remove the impediment?
  • And where is the concrete, the real problem?

In order for impediments to be communicated at all, the Scrum Master should encourage the developers to name problems and, if necessary, eliminate them themselves. Both is only possible if there is mutual trust.

The Visualisation with Impediment Boards

An Impediment Board visualises problems and obstacles that limit a team or individual team members at work. It can also be understood as a representation of the lifecycles of individual obstacles. The advantage of the Impediment Board lies in the simplicity of the visualisation and the access to information. The visualisation usually takes place in a representation with three or four columns. The first column “Identified Problems” is optional, because every further problem could also end up directly in the column “To be solved”. All in all, the columns show the states of the obstacles.

Ideally, all participants should have access to the display, as this makes it easy for them to see which Impediements have been identified and what their processing status is. This successively contributes to the improvement of working conditions and increases transparency. The level of commitment also increases, as it quickly becomes clear that one goal is to eliminate concrete problems. And this also leads to a feeling of mutual appreciation, because problems are taken seriously and eliminated step by step.

There are organisations that mark Impediments directly on the taskboard, either by small markers like dots on a task or by a separate area next to the tasks. “The more obstacles are documented during the sprint, the more the achievement is endangered” – this could be one interpretation. In terms of content, however, such an interpretation is imprecise, especially since the risk of missing the sprint goal cannot be deduced directly from the number of Impediments. It is therefore advisable to use an Impediment Board, possibly even with an enrichment of additional information such as hints for solving the problems, possible key figures and priorities, contact persons for solutions or time windows. There are few limits to creativity here.

The Management of Impediments

There are two ways to manage Impediments: besides the already described Impediment Board you can also manage Impediments in backlogs. In some organisations, both techniques are used in parallel to deal with obstacles. Opinions differ as to whether it makes sense to maintain a separate impediment backlog or whether it is not sufficient to include the obstacles in the general backlog with a corresponding label.

Examples for Impediments

In principle, an Impediment can be anything that hampers a team in the performance of its activities. Examples:

  • The Scrum Master is too often in the home office.
  • The Product Owner is too rarely available.
  • There are sick employees and thus the sprint goal is endangered.
  • There are not enough software licenses for parallel use in the team.
  • Skills are missing in the team.
  • The monitors are too small and the computers are outdated.
  • There are delays with suppliers.
  • There is a conflict between team members.
  • I have a problem with debugging XYZ.
  • The user stories are badly written.

Not all of the examples mentioned need to be Impediments, because a problem is only an Impediment if it exceeds the capabilities of the team’s self-organisation. A lack of skills could possibly be an obstacle that a team solves itself over time. It may also be possible to resolve a conflict between team members through a moderated discussion. A slightly different interpretation separates internal and external Impediments. In the common definition there are no internal Impediments, because these can be solved by the team itself. The Scrum Master takes care of the solution of external problems either alone or with the team, in cooperation with the management or with a “third party”.

​Challenges with Impediments

There are some challenges when working with Impediments:

  • It is important that the problems, which may be managed by the Scrum Master, do not disappear in a backlog, but are easily accessible for the team at any time. This promotes the discussion and solution of the problems and prevents them from being suppressed or even forgotten.
  • Even if you work very well together in a team, there is still room for improvement. It is therefore practically impossible for an Impediment Board to be empty. If necessary, the Scrum Master has to help more with identification or create a more open climate for communication.
  • If there is no change in the conditions of the problems, the work with Impediments, the work and ability of the Scrum Master and the standing of the team as a whole will be questioned. This should be avoided at all costs.
  • If the obstacles add up without others being removed, not only the sprint goal but possibly the whole project is at risk. This must lead to an escalation, to prioritisation of the problems and, if necessary, to support by an additional force from “outside”.
  • The Scrum master is practically never alone responsible for eliminating the problems. It should be the interest of the whole organisation – if necessary after discussion of the content – to remove all obstacles.

Depending on the size of the problem, a quick solution is not always easy. Also in such cases the progress should be documented and communicated openly with the team and the management.

Tips and Tricks for Impediments

​Dealing with Impediments is not always easy. There are a number of tips and tricks that can help to document and remove the obstacles:

  • There is no reason to wait for the next Daily Scrum to communicate an urgent problem. If the scanner, air conditioner or computer fails, quick help is needed.
  • Not only at the Daily Scrum, but also when handling Impediments, an orientation towards the sprint goal offers itself. If an obstacle endangers the sprint goal, it must be repaired quickly in any case.
  • The documentation of fixed problems conveys a good feeling – the “successes” can easily be visualised even after a sprint, e.g. for an entire release.
  • When dealing with problems, trust is very important.  Possible conflicts, missing skills or difficulties in the cooperation with the Product Owner or the Scrum Master concern the team. A visualisation via Impediment Board, which is visible for everyone – and thus also for external team members or even customers – could undermine this trust.
  • The documentation of the obstacles should be used as input for the Sprint Review and the Sprint Retrospective.
  • If necessary, prioritization of problems makes sense. This makes it clear that a blockade, i.e. an obstacle to a single task, can be less important than an Impediment that jeopardises all progress in the Sprint.
  • Even if the Scrum Master should primarily ensure that problems are eliminated, the Product Owner also has an important role. Next to the Scrum team, he is the one who communicates with stakeholders, works with suppliers and communicates with the company management. A good cooperation between Scrum Master and Product Owner is therefore very important.

Impediment removal is a skill that the Scrum Master and the Scrum Team can perfect over time. It’s not uncommon for the visualisation of the Impediment Board to vary over time, perhaps additional information will be added to the board, perhaps some other information will disappear. It is important that it is a tool to eliminate problems as quickly and sustainably as possible.

Impediment Guide Download

Do you want to download the Impediment Guide for free?

Everything you need to know about impediments at a glance.

  • Definition and Visualisation
  • Examples and Tasks
  • Management
  • Tips and Tricks

Knowledge on 7 pages to take away.

Notes:

Feel free to share or link to the content on this page.

Here you can find a German podcast on the topic: Removing impediments as a Scrum Master.

Here you will find an article on Visible and Invisible Impediments by Robert Galen.

And here you will find additional information from our t2informatik Blog:

t2informatik Blog: The biggest ostacles in requirements engineering

The biggest ostacles in requirements engineering

t2informatik Blog: Agility? We tried it! Does not work!

Agility? We tried it! Does not work!

t2informatik Blog: What if? – A call to thought experiments

What if? – A call to thought experiments