Blockers and Impediments

When working with work, planning, or testing entities you may come across a blocking issue that prevents you from moving forward. For example, a key developer is sick halting work on an entity, or the QA team needs to run a test case that cannot be verified until the bug is fixed. That’s what we call a Blocker or an Impediment.

There are two ways to add a Blocker to your project:

Impediment entity
Blocker Relation

Impediment Entities

An Impediment entity is a standalone card. As with most entities across the system, an Impediment also has its own ID number and Name.

Impediment

Every Impediment entity can contain Description, Owner (creator), parent Project, current State, Priority (business value), Planned start and end dates, Custom Fields, Comments thread and Tags cloud. All these fields are displayed when you open details view for an Impediment.

Impediments can be created for any Assignable entity including User Stories, Bugs, Tasks, and Features.

When an Impediment is connected to an Assignable work item, a link to a blocked entity is shown in Info panel of Impediment details view:

Whenever you select an Assignable entity for an Impediment, a Blocker Relation between the Impediment and the Assignable entity is created automatically.

In the example below, the Bug #47627 is blocked by an open Impediment #47310 and this fact is reflected in the Relations tab of the Bug:

Whenever you edit an Impediment and remove the link to its Assignable entity, the Relation between them is also automatically deleted.

If you would like to link an Impediment to more than one Task or Story, you can manually add a Blocker Relation between them.

Impediments can represent issues, obstacles, or force majeure circumstances.

Blocker Relations

It is possible you may not have any flow-blocking issues or events. Instead, you may want to reflect a fact that two pieces of work are closely tied and that some work items cannot be completed before some other work items. For example, the core team is working on an API and until it is complete the other teams cannot make progress on certain work items. Or, the infrastructure team is doing some technical maintenance, hence the production team's work is on hold until the maintenance is done. Keeping these informal dependencies in your head can be tiresome, this is where Relations help to organize the logical order in which the work should be completed and plan and/or prioritize your backlog.

A Blocker Relation is not a standalone entity. Instead, it is a direct link that connects two assignable entities. The link is shown in the Relations tab of the Detailed view for both entities.

In the following figure an open Bug #72446 is shown as an Inbound Blocker for a User Story #72178. The Blocker is Open and this is why the indicator in the header of the Relations tab is highlighted with red color.

Blocker Relations

Relations do not have their own numbers, names, detailed descriptions, or states. They can be added and removed only.

If there is an open Blocker Relation or there are related open Impediments, the Relation number will be marked as having red background.

A User Story with 3 inbound Relations. Unresolved Blockers are among them.

In the meantime, completed Blockers do not generate any alerts and are always shown in gray.

Blockers and Impediments in Targetprocess do not actually prevent users from making changes to related items. Blockers also do not affect progress calculations and forecasts. They function only as visual indicators of work item dependence.

Work with Impediments

You can add an Impediment to any card by opening the card’s properties and clicking the [+] button as shown on the picture below:

The Global +Add button can be also used for the same purpose.

Every Impediment must be added into some parent Project which serves as a container for this Impediment. Only users listed in the People tab of the Project with a role having 'Add/Edit Impediments' permission can create new Impediments.

Private Impediments

Private Impediments have been removed in v3.11.3.

Manage Impediments on a Board View

Unlike all Assignable entities in Targetprocess, the workflow for Impediments is limited with the following two States:

• Open
• Resolved

Custom processes and workflows for Impediments are not supported currently.

However, it is possible to create a Kanban board view showing Impediments as cards and states as columns. An example follows below.

In this particular case we see that the majority of our Impediments are issues involving the customer. Empowered with this knowledge, we can consult our Account Management department and improve our customer relationship to reduce the number of Impediments.

The following setup of the View is used:

• Cards: Impediments
• Horizontal Lanes: Blocker Category (Custom Fields)
• Vertical Lanes: States

Predefined Views

Open Impediments (Kanban Team)

The view named Open Impediments helps you to see all open blockers so they can be acted on quickly.

This view can be added to your tool as a part of predefined Kanban Team solution.

Open Risks (Project Portfolio Management)

In the Project Portfolio Management solution Risks are used as a Custom Term for Impediments. All of the open Risks are shown in the Risks view as a list. Here you can see who is working on them and what the status is.

Risk Management solution

Risk Management solution consists of 6 views, 3 reports, and 1 dashboard. You can install the whole solution or select the specific views which meet your needs.

Impediments on Dashboards

Special widget showing list of recently created impediments can be added to your Dashboard.

Indicators of Impediments

Customizing Cards

To increase the Kanban Board's utility, we may want to see important details as card units. In the Customize Cards tab of view settings we can drag-and-drop different card properties onto a card such as Card ID, Relations to other cards, Number of Impediments, Assigned Person, and Estimated Effort.

Now our view shows a lot of relevant information at once.

Flow Tab

Whenever a User Story or Bug has an assigned Impediment, its Flow tab changes the color from the regular green to warning orange.

Custom Reports

In Custom Reports, an Inner list of Impediments can be embedded into a list with any Assignable entity(ies):

Shortcut Link to an Impediment with Known Numeric ID

Using ID:1234 syntax it is possible insert a shortcut to an Impediment (or any other entity) into the description or comment:

Bulk Addition of Impediments

Impediment entities can be imported from a CSV file.

Several Impediments can be created at a time from the list of names in a .txt file with the help of the Quick Add Several Work Items mashup extension.

Process Customization

Regardless of what process you use, Targetprocess allows you to customise the terminology your process uses. "Impediment" term can be changed to something more relevant to your particular process. Use Terms settings for this purpose.

You can not edit states or change the default process workflow for Impediments.

Is it not possible to have more then one person responsible for an Impediment.

Automation

You can set up email notifications for your Impediments in the process workflow settings.

It is not possible to send an email when a person is set as responsible for Impediment. However, as a workaround, it is possible to submit a comment to the created Impediment and @mention that person in the comment text, or add the check-box below the comment to notify 'Assigned User'. The 'Add comment' event can be activated in the email notifications settings for an Impediment workflow.

Changes related to Impediment entities are supported by Follow / Watch notifications.

Work with Blocker Relations

You can create a Relation for any entity (User Story, Bug, Feature, Task, etc.) from the Relations tab in Detailed views. To create a Relation with an existing entity(ies) please click on the ‘magnifier’ sign.

To add a new entity and create a Relation with it in one step, you can use ‘quick add’.

The Relations can be identified as a Dependency, Relation, Link, Duplicate, or Blocker at your discretion. Relation type should be selected based on suitability in each particular case. The type of added Relation can be easily changed:

Only Blocker Relations generate red-colored highlighting warnings. Relations of other types do not create such alerts.

Blocker Relations on Views

In the graphic below we can see that the User Story has two inbound related Bugs, one of which is a Blocker, and one outbound related Feature. It means that we will need to close these Bugs (i.e resolve the inbound Relations), then implement the User Story, and only after the User Story has been completed can we start working on the outbound Feature.

These relations can be visualized in the form of cards and lanes on boards.

Filters for Blocker Relations

It is possible to apply filters to your cards (entities) in order to highlight or include into your view or report only those having Blockers and Impediments. The most common examples of them are as follows:

Filters for Cards (Assignable Entities such as User Stories, Tasks, Bugs, Features etc.):

?InboundRelations.Where(RelationType is 'Blocker')

- this filter for cards shows only entities with inbound blockers.

?InboundRelations.Where(Inbound.EndDate is None and RelationType is 'Blocker') or Impediments.Where(EntityState.IsFinal is False)

- this more complex filter for cards shows only entities with unresolved blocker relations and open impediments.

Filters for Lanes where Relations are Used as Lanes on Board Views:

?OutboundRelations.Where(RelationType is 'Blocker')

- this filter for Inbound Relation lane shows entities with outbound blockers

?InboundRelations.Where(RelationType is 'Blocker')

- this filter for Outbound Relation lane shows entities with inbound blockers.