Kanban Evergreen: Should We Include Waiting or Blocked Items in WIP Limits?
A few weeks ago we asked: “Should you include waiting or blocked items in WIP Limits?”
Here are the results of the poll:
Most participants in the poll responded that they would either include waiting or blocked items in work in progress limits or that they already do so.
Let’s examine what we can learn about this case from the Kanban Maturity Model.
Types of Blockers
In our Kanban foundation-level courses (Kanban Management Professional), participants learn that we identify and recognize three types of blockers or waiting items:
First of all, one should define how blockages are visualized and what information is recorded about the blocking issues for the appropriate management and further analysis.
Because of their negative effects on service delivery, blocked work items usually are marked by means of a symbol or a sticky note of a preselected color. They stay in the swim lane and column in which they are blocked, and they add to the WIP for that column. This might create tension because it impedes pulling work into the column, but it also encourages fast resolution of blockages.
Out of all blockages:
- Define what kind of blocking issues can be resolved autonomously by the teams
- Define what kind of blocking issues have to be escalated to what organizational role and by what means
- The policy for escalating blocking issues has to be agreed on collaboratively by those involved and the affected stakeholders, and it must be documented and made explicit to the workers who use that policy (1)
Parking Lot
Sometimes a work item is waiting on an external group (another service, customer, or supplier) and stays in this state for a certain amount of time (e.g., by a certain date). When little or nothing can be done to shorten the waiting, the ticket representing the work item can be moved to a “parking lot” until the end of the expected time.
You should designate a special area of the kanban board, a parking lot, for placing tickets that are currently waiting on an external group.
There are variants of this pattern that may involve spawning a new ticket with peer-to-peer dependency on the original. The new peer is placed in the parking lot, and a visual indicator, such as a smaller ticket of a similar color, is placed on the ticket that spawned the external request.
Make sure to track the time the card spends in the parking lot.
As soon as the agreed waiting time (service level expectation [SLE]) expires, mark and manage the work item as blocked (2).
What About the WIP Limit?
A dependency parking lot buffers work between one kanban system and another. If the dependent system exhibits stability and predictable lead times, then it is possible to limit WIP in a dependency buffer without causing too much stress.
Even if the dependent system doesn’t exhibit stability and predictability, a WIP limit can still be set for the buffer to avoid losing sight of the stopped work. The WIP limit acts as a stressor, potentially causing upstream stalling within the kanban system. This stress can be discussed at a Service Delivery Review (FL 3.4) and escalated at an Operations Review (FL 4.2).
The WIP limit established for the first time should be set slightly higher than the average WIP. Assuming the dependency parking lot buffer was previously unbounded, a study of historical data will suggest an upper limit, and the new WIP limit should be set somewhere between the upper limit and the mean calculated using Little’s Law.
You should adjust the WIP limit empirically; it should be a topic of discussion at Service Delivery Reviews until a stable value has been realized (3).
Is it a Stressor?
Yes!
Telling people who have never limited waiting or blocked items before to start doing so will potentially create very strong stress and resistance coming from the system.
Hence, you should consider introducing these practices carefully.
Please note that the practices which we are examining to answer the question of whether waiting or blocked items should be included in WIP limits or not, come from Maturity Level 3 (transition) and Maturity Level 4 (consolidation).
The practice which explicitly says about introducing WIP limits on the dependency parking lot is practice LW 4.1 (Limit WIP for a dependency parking lot). This is our Maturity Level 4 consolidation practice. Hence, including blocked or waiting items in work in progress limits too soon (when you recognize that your organization is at Maturity Level 0, 1, or 2) may result in too much stress, too heavy resistance, and rejecting the practice. Remember to avoid overreaching (4)!
Learn more about managing waiting or blocked items in our Kanban Management Professional classes!
**********************************
- XP 3.0 Define policies for managing blocking issues, read more: https://kmm.plus/en/book/practice/XP%203.0/
- VZ 3.9 Use a parking lot to visualize currently waiting or blocked work requests dependent on another service or system, read more: https://kmm.plus/en/book/practice/VZ%203.9/
- LW 4.1 Limit WIP for a dependency parking lot, read more: https://kmm.plus/en/book/practice/LW%204.1/
- Overreaching, read more: https://kmm.plus/en/book/introduction/4.3/
