nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Blockers and impediments - how to deal with them on the board

Kevin Dickson_358dbj

Hi community,

By definition,
1. An impediment is an event that impedes any of the developers from working to their anticipated sprint capacity.”
2. A blocker refers to a situation where work has completely halted on an item and cannot progress without eliminating the issue.
"...An impediment slows progress, but a blocker halts progress"

What is the best way to handle both of these issue types on a Scrum board?

Do we create a new ticket for the blocker/impediment, and link these to the affected story or subtask? or do we change the issue type status of the story or subtask?
Would it be beneficial to create a column for blockers+impediments, and move the newly created(?) and stories/subtasks to the new "blocked" column?

And thank you all, in advance.

Accepted answers

Bill Sheboy

Hi @Kevin Dickson

IMHO, that distinction may not matter; it seems the symptom is work is not able to progress as expected, and so how can we make that visible so action can be taken.

I recommend using one-and-only-one way to indicate "hey, I need help and cannot proceed". If there is an element of waiting for something/someone, consider using the built-in flag feature to raise visibility, and check back when the team thought the issue should have cleared. In all other cases, I'd recommend "stopping the line", asking for help, and swarming to clear the issue as a team. And in a retrospective, discuss how to eliminate/mitigate such impacts in the future.

One thing I would not recommend: adding a status column to the Jira board for "blocked" or "impediment". Slow downs in flow should be treated as exceptions, and opportunities to learn how to work better. Adding such a blocked step to the board makes blockages a normal part of workflow, and disincentives the team from improving or even clearing the blockage.

An exception to that would be teams using a Kanban process where their analysis indicated a need for waiting/buffer steps to smooth the flow.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Kevin Dickson

IMHO, that distinction may not matter; it seems the symptom is work is not able to progress as expected, and so how can we make that visible so action can be taken.

An exception to that would be teams using a Kanban process where their analysis indicated a need for waiting/buffer steps to smooth the flow.

Kind regards,
Bill

Kevin Dickson_358dbj

Thanks, Bill

Good points. The issue I face though is that we have external vendors and other teams such as DevOps that are sometimes required to resolve a blocker for us.
They are often working on "other issues" and so cannot be immediately available for us.

If it's an impediment internal to the team, then I fully support the team swarming to resolve, however the majority of our blockers come from 3rd-parties or other teams, and we have to schedule time with them to resolve, often a few days in the future.

So, I'm looking for the best way to make these visble on my radar via the board, as often times they get forgotten about with no follow up by the team themselves, until I uncover them down the line.

But, will have a think about your suggestions, they are valid.

Also, and perhaps just as importantly, what are your suggestions around creating blockers and impediments as new issues and linking them to the affected issue?
I'm against this as it just creates havoc on the board.
I'd rather they just either moved the story/subtask to a blocked column, or flagged and commented on same ticket - as per your suggestion.
I don't understand why anyone would want to create a seperate impediment ticket, unless is exclusively stands on its own as a larger blocker to the team. However since they're a default issuetype created within Jira, they must be there for a reason?

Bill Sheboy

In my experience, a better way to handle dependencies is to eliminate them rather than try to manage them. For example...

When two teams have dependent work, can one of the teams fully own it to completely remove the dependency? This could involve conversations about adjusting separation of duties concerns, or automating things like releases so dependent teams (e.g., operations) are no longer needed as players.
When that is not possible, consider how to split the work into distinct/completable chunks: A > B > C > D. Then dependency is handled with scheduling, and one team would not start an item until the dependent work is completed by their partner team. Product Owners and Delivery Team members can help with that scheduling.
And sometimes, work just happens in parallel. Regarding your question about visibility, you could use the built-in flags (ensuring people always add a comment to describe the dependency/impediment), and then use Jira board swim lanes to put those items at the top of the board, with the JQL of

Flagged = Impediment

On your last point, I understand why teams might use "blocked" steps or "impediment tickets". Perhaps they are still learning about improving their flow and have not realized the impacts and costs of dependency management for everyday work. Although going to the trouble of creating an issueType for this symptom seems like their Jira admin could perhaps chat with their coaching staff to learn other options.

Kevin Dickson_358dbj

Fair points, Bill.

Thank you for your insights, I'll see how I can apply them.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

atl-orange