Dealing With Blocked Work Items In Kanban

There are two approaches to dealing with the blocked work items issue.

The first approach will ease flow, but at the expense of lead time and possibly quality. You can improve flow by having a larger overall WIP limit -- achieved through either explicit buffering or by using a policy with less restriction on WIP, for example, 3 things per person, on average, rather than 1.2 things per person. The greater WIP limit means that while something is blocked, the team members can be working on other items. I recommend this approach for immature organizations. [...] Leads time will be longer, but this may not be an issue in many domains. The spread of variation might be greater, and so lead times will be less predictable; however they still may be more predictable through the use of a kanban system than they were before. The biggest drawback to using greater WIP limits is that there is less (or no) tension to provoke discussion and implementation of improvements. There is consequently no pressure to improve: The catalytic effect of kanban is lost.

The second approach is to pursue issue management and resolution relentlessly and as the team matures, to move toward root-cause analysis and elimination with specific improvements designed to prevent assignable-cause variations in the future. In this approach, you leave the WIP limits, buffer sizes, and working policies fairly tight, and you cause the work to stop when things become blocked. Idle time for those people assigned to blocked work raises awareness of the blocking issue. It may cause a swarming behavior to try and fix the issue, which has been seen to encourage those idle team members to think about root causes and possible process changes that will reduce or eliminate the possibility of recurrence. Keeping WIP limits tight and pursuing issue management and resolution as a capability has been seen to create a culture of continuous improvement.


By marking items as blocked and raising visibility on to the source of the blockage, the management, team, and value-stream stakeholders will become aware of the impact of such coordination challenges.

This awareness should lead to some behavioral changes that improve the situation.


Preferably, the features of the electronic [issue tracking] system should allow the reason for the blockage to be tracked separately, or blocking issues should be tracked as first-class work items linked to the customer-valued item that is dependent upon resolution of the issue.


Blocked work items require an organization to develop a capability for issue management and resolution to restore flow as quickly as possible, as well as a capability at root-cause analysis and resolution to prevent recurrence.


It is not enough simply to mark and track work as blocked. [...] [M]y observation of teams around the world has been that knowing something is blocked does not lead to developing a strong capability for getting it unblocked.

It is essential to track the reason for the blockage and to treat it as a first-class work item, albeit a failure-load work item. A special work item type, Issue, is set aside for this purpose. [...] They should be assigned a tracking number, and a team member -- usually the project manager -- should be assiged to ensure resolution.

-- David J. Anderson

from "Kanban"

Quoted on Mon Aug 13th, 2012