Little’s Law: It’s about WIP

When we discuss Kanban and WIP limits Little’s law is often quoted. I set out to get an understanding about what it is and how we can use it to help us as we learn about Kanban.

The first place to look was Wikipedia and this is what I found:

In queueing theory, a discipline within the mathematical theory of probability, Little’s result, theorem, lemma, law or formula[1][2] is a theorem by John Little which states:

The long-term average number of customers in a stable system L is equal to the long-term average effective arrival rate, λ, multiplied by the (Palm‑)average time a customer spends in the system, W; or expressed algebraically: L = λW.

A little further digging and I discovered that Little’s example was applied in a shop context. How can we apply this to Kanban?

The first step is to understand how we can map Little’s formula to things that have meaning in Kanban. From the above equation we can say L represents the Work In Progress Limit (WIP),  the arrival rate, λ, is equivalent to the Kanban concept of Throughput (TP) and W can be mapped to the Lead Time (LT).

Lets try out the theorem and see if it works:

Work In Progress = Throughput * Lead Time

In one of my teams the Lead Time is 6 days. The Throughput is 11 items a month. I have to convert the Throughput value to use the same units as the Lead Time so lets assume there are 20 working days / month and calculate Throughput as 11/20 which gives us a Throughput of 0.55.

Work In Progress = 0.55 * 6 = 3.3

So we get a WIP of 3.3 for this system. This makes sense as our WIP is currently 4 and we sometimes run below this limit.

So what other information does this theorem tell us? How about if we swap round the formula?

Lead Time = Work In Progress/Throughput

If the theorem holds true this tells us that the LT will reduce if either the WIP is reduced in a system or the TP is increased.

This is the most common way Little’s law is expressed in the Kanban context. Why is reducing LT important? Well – the longer it takes for items to be completed the less value they have to the customer. The longer an item remains in progress the higher the chance that requirements might change or the need for the item changes. The cost of delay is also worth considering too.

So how would we go about decreasing LT? We could try to improve the TP. In order to do this we could hire more people for the team or we could improve the technologies we are using. These both tend to be quite difficult to achieve and may have knock on effects to other aspects of the team like moral while having significant ramp up times.

An easier option would be to reduce the WIP. We could commit as a team to reduce the WIP to an agreed level.

In the software development context reducing the WIP means that items can be delivered faster and with greater predictability (based purely on shorter LT).

It’s common practice in Kanban to reduce WIP. Little’s law forms the basis of this concept. When we talk as a team about reducing WIP we talk about things like context switching and improved focus which are both positive consequences of reducing the WIP. While this article covers a very generalised view of Little’s Law it’s helpful to have some level of awareness towards the law. It enables us to think of the underlying principles of Kanban when introducing the WIP concept to teams which will ultimately help them improve. It’s useful to bring out this equation when introducing teams to Kanban to help emphasise the importance of monitoring and reducing WIP.

Here is an short video which helps to get across some of these ideas:

Why WIP makes sense


In this article I’m going to describe how by changing the focus of a team we can improve the way we work.

So how do we get a team to focus on the work that’s important? One way is to prioritize the topics in any conversations a team has so that the most important pieces of work are discussed first.

I coach a team practicing Kanban and every morning we have a stand up. For this we gather round the Kanban board and begin to talk about the items on it.

A typical Kanban board
We like to talk about the most important items first so we usually start off discussing the blocked items and what we can do to unblock them.Once these items have been covered we then moved to the items further down the board. We naturally start off at the left side of the board and work our way across towards the right side.

However we should ask ourselves – are stories in the backlog really the most important items for us to chat about? A phrase often used in the Kanban world is “Stop starting, Start finishing”. This tells us that our focus should be on finishing stories. To enable this I suggested we begin the stand up by talking about the items that are closest to being complete. Simply – we started to read the board from right to left.

As a result, the team became more focused on completing the items closest to being finished. By focusing in on the items closest to being completed we have seen a drastic reduction in our cycle time. This was reduced from several weeks down to 7-8 days.

Changing the way we read the board means that the last thing for the team to talk about in the stand up is the backlog and whether we could bring something in to work on. It makes sense to discuss this last in the stand up once we have a good understanding of our current state.

This change is a major factor in us thinking about Kanban as a pull system rather than the push mentality we had before.