Work in progress (WIP)

In production and supply-chain management, the term work-in-progress (WIP) describes partially finished goods awaiting completion. When implemented correctly, WIP limits expose inefficiencies and encourage teams to address them, leading to continuous improvement.

WIP limit

A Kanban measurement, denoting the number of work items allowed to be in a given workflow state. Process rules govern what happens when a WIP limit is exceeded; usually work stops and all workers swarm to resolve the issue.

Importance of limiting WIP

Limiting Work In Progress (WIP) is a core practice in Kanban, essential for creating a smooth, efficient workflow. Think of it like this: instead of pushing work through the system, each stage "pulls" work from the previous stage only when it has the capacity. By setting limits on the amount of work allowed at each stage (or key stages), you prevent bottlenecks and ensure a steady flow.

WIP limits can act as early warning systems, highlighting bottlenecks and areas where the workflow is struggling. While it's tempting to apply WIP limits everywhere, the most effective systems often focus on the most impactful bottleneck to avoid creating new choke points. Overly restrictive limits can create new problems, so it's important to find the right balance. An example is stop lights at highway entrance ramps: they create backups on the entrance ramp regardless of whether the highway is busy.

Setting WIP

Source: Evan Leybourn, with some rewording to improve clarity.

First, gather some information:

1. Note your team size
2. Establish a value stream map
3. Determine your value added (VA) time and non-value added (NVA) time
   • Value-added time (VA) is time spent directly transforming your inputs to the output $=\text{cycle time}$
   • Non-value added time (NVA) is the rest of the time from start to finish; it's waste! $=\text{lead time}-\text{cycle time}$
   • Note that you can merge two steps in a VSM if there's an NVA of zero in between
4. Calculate your process efficiency:

Calculations to determine starting WIP

Then, do some calculations:

We'll start by assuming that your team only works on one process. If there are multiple Value Stream Mapping's for the team, you will need to adjust accordingly by the percentage of time spend per VSM.

Efficiency

Start with your efficiency. An efficiency of 50% means that your team can do 2 things simultaneously. An efficiency of 90% means that you have very little time between each step, so you can really only do 1 task at a time. And an efficiency of 10% means that you have lots of time between steps, so your team can do 10 simultaneous tasks.

Divide your team size by your efficiency to get the total number of tasks your team can perform simultaneously:

$\text{simultaneous task capacity}=\text{team size}÷\text{efficiency}$

This total will be our total WIP for the entire board. Of course our goal is to improve efficiency (and thus lower WIP — Chuck), but we are looking for our current WIP, based on the current process.

Develop Feature: Team size = 7, Efficiency = 55%, 
	Total tasks = 7/55% ~ 13 tasks

Hiring Staff: Team size = 2, Efficiency = 27%, 
	Total tasks = 2/27% ~ 7 tasks

Helpdesk Requests: Team size = 3, Efficiency = 65%, 
	Total tasks = 3/65% ~ 5 tasks

Tasks by state

Next, we proportion out our total number of tasks by state. Think of the number of tasks as slots. So if we spend 40% of our value-add (VA) time in "Do", then assign 40% of the task slots to the "Do" action, and so on.

Round these numbers down. Make sure that all 0's are at least 1 by reassigning task slots from other activities, and you have your initial WIP limits. See that reassignment in the Helpdesk example.

Develop Feature (13): 

Design: 13 * 15% = 1.95 ~ 2 
Develop: 13 * 55% = 7.15 ~ 7 
Test: 13 * 28% = 3.6 ~ 3 
Deploy: 13 * 2% = 0.25 ~ 1

So we estimate that the team of 7 for Develop Features can simultaneously work on 13 tasks based on their process efficiency. The area I would look out for here is Test; this may end up being a bottleneck because the Deploy step is, comparatively, so much faster.

Hiring Staff (7): 

Write PD/Advertise Position: 7 * 25% = 1.75 ~ 2 
Interview Candidates: 7 * 50% = 3.5 ~ 3 
Select Candidates: 7 * 25% = 1.75 ~ 2

Hiring Staff is a lot more straightforward; given the team of 2 and the low process efficiency, the recruiters in this team can hire for 7 positions simultaneously. As long as our initial assessment of VA and NVA was correct, this shouldn't form any consistent bottlenecks.

Helpdesk Requests (5): 

Triage: 5 * 4% = 0.2 ~ 1 
Assign: 5 * 2% = 0.1 ~ 1 
Resolve: 5 * 90% = 4.5 ~ 2 
Close: 5 * 4% = 0.2 ~ 1

Finally, Helpdesk Requests is a problem. Because each column needs a WIP of at least 1, Resolve lost two slots and is going to be a significant bottleneck. In this case, common sense would suggest increasing the total WIP so Resolve could be brought to 4 or even 9.

Keeping in mind the point above about merging two tasks if the non-value add (NVA) time between them is zero, you could also address this by combining some of the smaller processes such as Triage and Assign. The combined status would still get a WIP of 1, leaving more slots for Resolve.