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 analyze 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 that 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 and Kanban
Remarkably, Little’s Law was found to apply to any number of other systems, including Kanban systems.
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
Little’s Law Assumptions in a Kanban System
There are several assumptions needed to make the law work:
- The average Arrival Rate is equal to the average Departure Rate
- All tasks entering the system will eventually exit the system once completed
- There should not be large variances in WIP between the beginning and the end of the time period examined
- The WIP average age should remain the same, neither increasing nor decreasing
- 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 behavior becomes more and more unpredictable.
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.
Making Predictions With Little’s Law
In order for the Law to be valid, we need to have all of its assumptions valid. So one prerequisite for the Law to work is to guarantee that all the assumptions won’t be violated in the future.
Even if that’s the case, the Little’s Law is still a relationship of averages as each component in the relationship is an average. This calculation will produce an average. We cannot make any probabilistic forecasts using this approach.
Making predictions based on an average can land you in some hot water. Forecasts based on averages would make sense only if you know something about the shape of the underlying distribution of your data. If you don’t there is no way to associate any percentile with the average value – there can be exactly 50% or much more than 50% or significantly less than 50% chance of that goal being achieved.
If we don’t know the distribution, then we cannot give a probability of where the average falls. And if we don’t know a probability, then we cannot make a forecast.
Little’s Law is an unreliable method of making future predictions. If you really want to get accurate delivery forecasts, then you should use tools like the Cycle Time Scatterplot or Monte Carlo Simulation.
Analyze 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 of the different parts of your process.
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 underutilized capacity (team members with nothing to do) should always focus on resolving a bottleneck as their first priority.
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 CoS. For example, we might want to use Little’s Law to analyze all work flowing through our system, or we may want to use it to just look at our Standard work items.
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 (Expedite and Fixed Delivery Date, 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 analyzing process performance.
Little’s Law is about examining what has happened in the past and analyzing the predictability of your system. The power of Little’s Law rests on the assumptions behind it. It provides a guide of a set of process policies to adopt in order to maintain a stable system. Instead of making predictions, adopt the Little’s Law assumptions as explicit policies to drive consistency and predictability of your workflow.
Additionally, it can be used to analyze your work by class of service to find where these assumptions break down. Most importantly, it gives a deeper understanding of how the three basic flow metrics are connected – and how changing one inevitably affects the other two.
Has Little’s Law helped you understand how the main flow metrics are connected? How did it help you analyze your own process performance? Tell us about your experience in the comments!
