Blocked work items : the most expensive work you're not managing

Many delivery teams focus on what's in progress and what’s left to do.
Very few actively manage what's blocked. In fact, I’ve known a fair few over the years who actively skipped over the blocked items.
That's not just a minor oversight, it's one of the most expensive blind spots in modern delivery systems.

Blocked work is flow’s worst enemy. It needs focused effort, but instead it is usually being ignored.


Blocked work is still WIP

This often confuses people, including initially myself. But, work typically becomes blocked after a work item is picked up to progress. Rarely we know about the block before we make a start. And if the work has started then it is consuming capacity whether anyone is touching it or not.
Yes, it would be easy to shift it aside and make space for another WIP slot, but that would remove the urgency to resolve it and blocked items will keep on aging.
Therefore blocked work occupies a WIP slot and with that affects, mental bandwidth, dependency attention, and forecasting confidence.
Treating blocked items as "paused" rather than actively harmful is how organisations end up with boards full of ageing work and no clear sense of why nothing finishes.
Blocked work doesn't stop costing you just because no one is coding. It might be counter-intuitive but unblocking work is your best shot at improving flow.


The problem with under-visualising blockers

Blocked items are often marked with a tiny icon, a comment field, a linked blocking work item, or a vague note like “waiting". Worse, often, they are sent to separate status column which makes them easy to ignore.
Sadly this defeats the purpose of visualisation and instead is more akin to concealment.
If someone can glance at your board and they are not able to immediately see how many items are blocked, where they are blocked, and how long they've been blocked, then blockers are not really being managed. It’s more like they are being tolerated.


Blockers as signals, not problems

There is a rather damaging delivery myth doing the rounds - that blockers are team-level issues.
It is not useful to see them as a team level issue.
Blocked work usually points to one or more of dependency mismanagement, unclear decision authority, missing policies, overloaded reviewers, external team bottlenecks, or priority conflicts created at a level above the team.
Teams can report blockers. But in reality, they cannot resolve most of them without leadership action.
When blocked items age that’s rarely an indication that the team isn't trying hard enough. It's usually because the system isn't designed to unblock itself.


Aging blocked work leads to compounding risk

Blocked items are a problem on their own but when left to age, things get much worse. Stay with me, I am not being over-dramatic.
When work is blocked, its age continues to increase which increases the risk to SLE, followed by reduced forecast reliability, and an impact to downstream work queues.
And when blocked work sits untouched and people forget that it exists until it becomes urgent, you end up with escalations, more pressure to deliver and that in turn increases variation and leads to unstable forecasts.
This is how "surprises" happen. The signal was there all along, but nobody was paying attention.


"Waiting" is not neutral

Many delivery workflows include a column that might be called "Waiting" or "On Hold”. I’ve witnessed work items sit in such columns for months, no real focus on unblocking them.
These on-hold work items are not harmless.
Waiting work delays customer feedback, inflates cycle time, increases coordination cost, and distorts throughput data.
If waiting items were harmless, flow wouldn't matter.
The longer something waits, the harder it is to restart quickly. Flow is affected because context evaporates and assumptions age, people move on to new work. Waiting is far from neutral, it is dangerous.


How to visualise blocked work effectively

Blocked work should be “in your face” and impossible to ignore.
There are three elements to doing this effectively

• Visually distinct from normal WIP so it is immediately obvious
• Clearly specified reason for the block
• Displaying elapsed blocked time

A good blocked signal should prompt the question "why is this still blocked?" — not "oh yeah, we know why that one’s waiting."
If a blocked item doesn't generate discomfort then the signal is too weak.


The case of too many blockers

When a system experiences frequent blockers it’s likely because it is too fragile.
Blockers indicate one or more of

• work is being started before prerequisites are met
• dependencies are discovered too late
• policies are implicit rather than explicit
• WIP limits are being bypassed in spirit.

These are difficult to fix that with better execution. But they can be fixed by changing when work is allowed to start and who is accountable for removing obstacles.
Blocked work is a signal. Starting work too early is usually the problem.


Leaders must act faster than teams can

Blocked items expose one of the most important asymmetries in delivery systems: teams feel the pain immediately, leaders often feel it only when something explodes.
By the time escalation reaches management, the work is usually already old, risky, and politically charged.
Visualising blocked work early allows leadership to intervene before urgency replaces reason. That is not micromanagement. It is system stewardship.


If blocked items don't trigger action, you may want to stop and reflect

You can do a simple test.
When an item becomes blocked take note:

• Does something change?
• Does someone intervene?
• Does priority shift?
• Does capacity get reallocated?

If the answer to these questions is "no", then blocked item visualisation is not doing its job.
Perhaps it’s time to stop and reflect.


Managing blocked work is where improvement starts

In the spirit of some of the lessons from the book “A beautiful constraint” (by Adam Morgan and Mark Barden) , blocked items can be turned into an advantage.  They could become a great source of improvement data you already have.
Blocked items history can tell you where policies are missing, where decisions have been slow, where coordination fails, and where WIP limits are not adding value.
All you need to do is to learn from that data and avoid repeating the same mistakes.


​A Blocked item should say "Act Now", and not "check back later"

Kanban is explicit about actively managing work in progress. Blocked work is the most significant indication that active management is required.
If blocked items are ageing and nothing is happening, then I am afraid you are not managing flow, you are just watching it slow down.
​
In the next post, we'll move into Forecasting with Historical Data, and why replacing confident guesses with probabilistic forecasts is one of the most powerful, even if uncomfortable, shifts delivery leaders can make.