Kanban – Set Work In Progress Limits

Avarteq_Kanban_BoardThis blogpost describes the Work In Progress (WIP) limits of the Kanban process and forms one of the five key values, which are as follows:

  • visualize the workflow
  • limit the Work in Progress
  • measure and manage flow
  • make process policies explicit
  • use models to recognize improvement opportunities

The implementation of WIP limits is related with advantages and disadvantages. The WIP can put pressure on the participants, but with a little discipline there is a significant and recognizable improvement in the quality and workflow.

The WIP limits is the number of ongoing work for each station and person in the process. The WIP should be kept as low as possible. Exceeding the WIP points out problems in the system that need to be examined and solved immediately. A tool for optimization is the consideration of the source of variability.

Limits for tasks

The WIP should be set in common with each member of the project and is to be defined for each producer, pairing partners, process-step and the whole process. The limit for each position  depends on the number of producers and their working time. In every project and team, the WIP limits can be set individually.

As a guideline it is considered, that each producer can only work on one task at a time.

The WIP limit can be adapted at any time. The decision to change a WIP limit should be made during a meeting with all the participants. The limits can be either increased or reduced.
They should be watched for some time, and can be adjusted after a while, if necessary.

The WIP limits reduce the number of blockers that slow down the workflow.

Limits for queues

The WIP for each column and queues should be as small as possible.
If this is given, variability can be restricted and the workflow can be maintained.
In the workflow of the Kanban system, there are buffers included to compensate for the bottlenecks.

Avarteq_Kanbanery_Kanban
Image 1: Kanbanery – Avarteq (www.kanbanery.com)

Buffer and bottlenecks

Bottlenecks are stations in the Kanban system. They arise when too many tasks extend the processing times of tasks between the stations. Bottlenecks caused by blockers or temporal events are fixed with the theory of constraints.

Buffer in the process should be as small as possible.
Buffer and queues increase the quantity of the whole WIP limit, they also increase the lead time of the tasks.
The size of the buffer and queues should be chosen wisely.

High quantity of the buffer  → increase the quantity of the WIP limit  → increase the lead time

Size of the input queue

The size of the input queue is given by the tasks in the prioritization meeting. The input queue should be refilling as fast as possible, in order to avoid the idle time.

The prioritization meeting depends on the size of the tasks and number of producers in the projects. The input queue can be refilled every day, weekly or monthly.

Unlimited sections

The theory of constraints deals with solutions in the workflow of the Kanban pull system, called the ‘Drum-Buffer-Rope’. After a bottleneck, the system allows practically no WIP.
The Kanban system provides WIP per column but sometimes there are exceptions, e.g. queue columns. The limits make it possible to respond to unexpected variability and protect the process for blocker and overfilling.
Kanban_bottleneck1
Kanban_bottleneck2

Image 2: Presentation of a pull-system with WIP – first line: Drum-Buffer-Rope / second line: Kanban system

Do not put pressure on the team

Young organizations can not handle problems with a small WIP, the result is, that all tasks are blocked and the workflow stops. For that reason try not to put pressure on the team with small WIP.
As already mentioned, choose the WIP for the columns and producers wisely.

Use the arising idle time for optimization. The process can be optimized in the code quality, brand new technologies or improvement of cooperation in the team and with the customer.

While introducing changes, e.g. adapt WIP, there is something you need to know: The J-Curve effect.
All changes produce a deterioration of the quality and motivation. However, along with time, the benefits are visible and the quality and motivation in the team arise.

J-Curve

Image 3: The J-Curve effect

Mistake – not set WIP

It is a mistake not to set WIP limits.
If no WIP is defined, faulty functions are not discovered in time and there is no continuous improvement.
With the WIP limits set, the process errors can be identified.

Allocation of capacity

If the WIP limits are set for the producers and columns, there has to be the WIP limit defined for the service classes / tasks types.
Each service class has a maximum capacity in the workflow.
The capacity could be as the following:

  • features 50%
  • change requests 30%
  • chores 10%

Conclusion

Define Work In Progress limits for each producer, column and service classes before the process is initially started.
All WIP can be adjusted empirically during the project. The limits preserve the system and workflow from blockers and stillstand.
Use the positive tension of the WiP limits in order to focus on the initiated work.

Sources

Anderson, David J. (2012): Kanban – Evolutionäres Change Management für IT-Organisationen, dpunkt.verlag, Heidelberg, page 121-130.

Sharing is caring!

One comment on “Kanban – Set Work In Progress Limits

  1. One way I like to set WIP with new teams is to start high, and lower it until it starts to be noticeable. Then, each time it poses a problem, ask if the best solution is to raise the WIP limit. Often, that is not the best solution to any particular problem. For example, “I can’t pull a task because the WIP limit is maxed.” “Should we raise it?” “It might be better if I help John on something he’s already started, then we can get rid of a blocker and free up WIP for new work.”

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.