I recently presented at a conference on the topic of **Work in Progress (WiP) limits**, and in particular Little’s law. As part of I gave a demonstration and from it drew the conclusion that WiP limits have no direct bearing on velocity.

This caused some controversy so I’ll try to explain again here.

### Applying Little’s Law

Mathematically speaking we can increase the speed with which we get served in two ways:

- We reduce the number of people in the queue (We limit WiP) or
- We increase the speed each person is served (We increase Throughput – in this case by adding more people, or installing faster equipment)

*Note: When mathematically applying Little’s law the pre-condition is that the variables are independent, the assumption is that number of people in the queue does not impact on how quickly the server works. This works in mathematics, but maybe not so much with people in reality.*

The principle is that WiP and Throughput are two independent variables and changing one does not change the other, only cycle time is impacted.

### The wider impact of WiP limits

Of course the goal of my talk was to illustrate that whilst you may feel you are getting more done by not limiting your WiP, and having a whole bunch of work in progress this has no bearing on your actual throughput which is governed by your bottle neck.

When using Little’s Law in a controlled environment we can show that limiting WiP doesn’t impact throughput (unless we limit it to less then our bottleneck and starve it – say two servers and limiting the queue to 1 person). What limiting WiP does do is reduce cycle-time enabling you to be more flexible and more responsive and to have more reliable forecasts.

## Work in Progress Limits will directly impact Cycle-time

#### Contradictory Claims

Unfortunately this contradicted one of my other claims in the presentation where I said that Limiting WiP helps increase throughput of the team.

The confusion of course is understandable, when using a mathematical example there is no cost for context switching and the example was to show the impact of WiP on a stable system isolating variables to demonstrate what happens. The real world is far more complex and there are many more variables.

**In the real world**

Generally speaking the ability to focus on less things means less multi-tasking, reduced cycle time means you have less things on the go at once, and for less time. These help you be more productive and thus indirectly the throughput will go up, but this is a result of you being able to focus not as a direct impact of the WiP limits.

There are many indirect benefits of using WiP limits, but Cycle-time is the prime beneficiary, the rest is a bonus or an indirect consequence.

One important knock-on effect of limiting WIP (reducing cycle time) is that your bottlenecks become much more visible. If I’m waiting a day for something in a 1-month cycle time, I might not even notice; in a 1 week cycle time, it’s an obvious problem. Since Empiricism depends on Transparency, so we can Inspect, so we can Adapt; making bottlenecks visible (through limiting WIP) accelerates continuous improvement and value delivery (velocity).

LikeLike