When a work item starts to age beyond expectation, teams often face a practical question:
Should we move it to Blocked,
or should we move it out of WIP altogether?
The answer matters more than it appears, because it determines whether the system merely acknowledges a problem—or actually restores control.
Aging Is a Control Signal, Not a Status
An aging breach means:
The assumptions under which the work was admitted are no longer valid.
- Capacity may have been overestimated.
- A dependency may have materialized.
- Scope may have expanded.
- Interrupts may have displaced effort.
Aging tells you a decision is required.
What you do next determines whether flow improves—or continues to degrade.
Option 1: Move the Item to “Blocked”
A Blocked state makes sense when:
-
The work cannot progress for a concrete, external reason
-
The blockage is explicit and understood
-
The team still intends to continue the item as-is
Examples include waiting for:
-
An external approval
-
An environment or test system
-
A dependency owned elsewhere
Blocked work should retain its age. From a flow perspective, it is still work in progress.
Blocked columns are good at making risk visible. They are not, by themselves, a flow correction.
Option 2: Remove the Item from WIP
Removing work from WIP (returning it to To Do or explicitly de-admitting it) is appropriate when:
-
The item cannot reasonably progress
-
Continuing it would starve other work of capacity
-
The cost of congestion exceeds the cost of delay
This is not failure.
It is correcting admission control.
Removing work from WIP:
-
Immediately frees capacity
-
Reduces cycle time pressure on remaining work
-
Restores honest flow signals
From a control-system perspective, this is the most direct corrective action available.
The Key Distinction
Here is the rule that resolves the confusion:
Blocked work is still WIP.
Removed work is not.
If your goal is:
-
Visibility of impediments → use Blocked
-
Restoring flow and capacity → remove the work from WIP
Many teams stop at visibility and never correct the load.
Definition: Persistent Blockage
Persistent blockage: a blocked item with no credible path or timeframe for resolution.
This means:
-
No known owner who can remove the blockage
-
No credible timeframe for resolution
-
No concrete next action that will unblock the work
-
Progress depends on conditions outside the team’s control
Time alone does not define persistence.
Uncertainty does.
Why This Definition Matters
A blockage with a clear path to resolution—even if it takes time—is still being actively managed.
A blockage without a line of sight to a resolution:
-
Consumes WIP indefinitely
-
Inflates cycle time
-
Accumulates cost
-
Distorts flow signals
From a flow perspective, such work is no longer “in progress” in any meaningful sense.
Aging Is Also a Proxy for Cost
There is a deeper reason this decision matters.
As work ages, cost accumulates.
-
Capital is tied up
-
Risk compounds
-
Options narrow
-
Opportunity cost increases
Age in progress is therefore a proxy for cost, even when no one is explicitly tracking dollars.
This is why aging is such a powerful signal.
Little’s Law, Reframed
Little’s Law is often stated as:
Cycle Time = WIP ÷ Throughput
In practice, this means:
-
As WIP increases, time in the system increases
-
As time increases, cost increases
Cycle time is not just a speed metric. It is a cost signal.
When work sits unfinished, it is consuming economic capacity without producing value.
Why “Blocked Forever” Is Expensive
Leaving large amounts of blocked work in progress means:
-
WIP stays high
-
Cycle time inflates
-
Cost accumulates silently
The system has acknowledged risk—but has not reduced it.
Removing work from WIP is often the cheapest decision, even when it feels uncomfortable.
A Practical Policy
Many teams benefit from a simple rule:
-
Short blockages → mark Blocked, swarm to resolve
-
Persistent blockages → remove from WIP and re-admit later
This keeps WIP honest and prevents aging from becoming normalized.
Workflow Policy Implication
A simple policy:
If there is no line of sight to resolving a blockage, the work should be removed from WIP and re-admitted only when conditions change.
This keeps WIP honest and prevents the system from paying indefinitely for stalled work.
Closing Thought
Blocked columns make problems visible.
Reducing WIP restores control.
And because aging is a proxy for cost, restoring control is not just about flow—it is about economics.
When work stops moving, the most important question is not:
“Why is this blocked?”
It is:
“Why are we still paying for it?”