When discussing Agile methodology and Kanban, one equation makes frequent appearances: Little’s Law. But what does this formula have to do with project management?

While originating from queuing theory, Little’s Law has been found to apply to all kinds of different systems – from retail to design to development. In Kanban, Little’s Law links the three basic metrics – throughput, cycle time and work in progress – in one simple formula.

Understanding how these Kanban metrics are connected allows you to analyse your work processes and see how changing one metric will affect the other two.

The history of Little’s Law

John Little came up with a theorem which connects the number of customers in a store with the rate that they arrive and the average time each customer spends there. This looks like this:

Average number of customers = Average arrival rate * Average time in the store

Consider a store where each customer spends on average 12 minutes (0.2 hours), with 10 customers arriving per hour.

Average number of customers = 10* 0.2 = 2

Little’s Law states that on average, 2 customers are in the store at any one time.

Little’s Law Assumptions

This deceptively simple formula can be applied to many systems. However, there are several assumptions needed to make the law work:

  1. The average Arrival Rate is equal to the average Departure Rate
  2. All tasks entering the system will eventually exit the system once completed
  3. There should not be large variances in WIP between the beginning and the end of the time period examined
  4. The WIP average age should remain the same, neither increasing nor decreasing
  5. Consistent units must be used to measure Cycle Time, WIP, and Throughput

Little’s Law is not influenced by the arrival process distribution, the service distribution, the service order, or practically anything else. As these assumptions become more inaccurate, the process behaviour becomes more and more unpredictable.

Little’s Law and Kanban

Remarkably, Little’s Law was found to apply to any number of other systems, including Kanban systems – so long as the five assumptions remain true.

In Kanban, WIP limits are applied to each process state – outstanding tasks must be completed before new tasks can enter a process state. Limiting work in progress allows the arrival and departure rate of tasks (throughput) to stay roughly the same in order to apply Little’s law and get accurate results.

In Kanban terms, Little’s Law is expressed a little differently, but the idea is the same:

WIP = Throughput * Cycle Time

If we imagine the Kanban board as the store, WIP is equivalent to the number of customers inside at any one time, throughput is the rate of customers passing through the store and cycle time measures how long each one spends inside the system.

This means that if two of the three values are known, the third value can be calculated – without knowing anything else about the tasks, team or project:

WIP = Throughput * Cycle Time

Cycle Time = WIP/Throughput

Throughput = WIP/Cycle Time

It’s important to remember that Little’s Law only deals with average values. Even if the assumptions do not hold for the entire time period under consideration, Little’s Law can still be applied. However, the more these assumptions are violated, the more the accuracy of the equation breaks down.

Little’s Law in action

Imagine you manage a widget-crafting project. You have four team members, and each team member has a widget-crafting capacity of one widget every two days – the average cycle time for the team is 2 days. Each team member works alone on their widget, giving a WIP of 4. This configuration gives your team an average throughput of 2 widgets/day.

What happens if we raise our WIP? As long as the assumptions hold, Little’s Law will still apply. However, this does not mean that doubling WIP will magically double your throughput while cycle time remains the same. It simply means that the formula will balance out – a change to WIP will cause cycle time or throughput or both to change and keep obeying the law.

Analyse Process Performance

So long as the five assumptions are accurate, Little’s Law applies to both the system as a whole and to its component parts. This allows you to get a deeper understanding about the different parts of your process.

Process States and Bottlenecks

Process states and bottlenecks

Tasks can only enter the next process state once they leave the previous state. This means that the throughput of the entire system cannot be higher than the throughput of the slowest step. In this way, bottlenecks cause the whole Kanban system to suffer. This means that underutilised capacity (team members with nothing to do) should always focus on resolving a bottleneck as their first priority.

 

WE UNCOVER THE EFFICIENCY OF YOUR WORKFLOW

Optimise your performance with Kanban analytics

See a dashboard with your data

Segmentation and Classes of Service

When segmenting WIP into different types with Classes of Service (CoS), Little’s Law can then be applied to each of the different type classes. For example, we might want to use Little’s Law to analyse all work flowing through our system, or we may want to use it to just look at our work items that are of type “features”.

We can investigate if our different segments are violating the assumptions of the law, and if so, how severely. Or maybe grouping two diverse segments together (maintenance requests and defects, for example) that is causing the issue. In most cases this type of segmentation is very useful and could provide a more sophisticated approach to analysing process performance.

This formula can be used to make simple predictions with minimal extra information, as long as the Little’s Law assumptions are valid. Additionally, it can be used to analyse different process states and CoS to find where these assumptions break down. Most importantly, it gives a deeper understanding of how the three basic metrics are connected – and how changing one inevitably affects the other two.

Has Little’s Law helped you understand how the Kanban metrics are connected? How did it help you analyse your own process performance? Tell us about your experience in the comments!

1 Star2 Stars3 Stars4 Stars5 Stars How helpful is this article? 6 votes