Sometimes I think it helps to go back to basics. And when using Lean Software Development, including Kanban, that means a man called Little and his Law. “Little’s Law” is a fundamental of queue theory and defines the relationship between Work in Progress (WIP), Throughput and Lead Time. It is the reason why Kanban teams try to limit WIP.
Little’s Law
Little proved the relationship between the average number of customers in a store, their arrival rate, and the average time in the store. Sounds pretty innocuous but as we’ll see it is the basis of Kanban.
The law is stated as a formula:
L = λ W
Where
L = average number of customers in the store
λ = average arrival rate
W = average time that a customer spends in the store
Little’s Law assumes a stable system so the arrival rate and departure rate are identical.
For example, assume customers arrive at the rate of 20 per hour (λ) and stay an average of 0.25 hour (W). This means we should find the average number of customers in the store at any time to be 5 (L).
L = 20 * 0.25 = 5
Little’s Law for a Kanban team
In the Kanban world of software development we use different terms to those in Little’s Law. So here is my version of Little’s Law using terminology commonly used by a Kanban team including Work in Progress (WIP), Throughput and Lead Time.
WIP = Throughput * LeadTime
Where
WIP = average number of items in process = L
Throughput = average departure rate = λ
LeadTime = average time an item spends in the system = W
WIP (Work in Progress) is the number of items being worked on by the team. In software development the unit of measure could be cards, user stories, scenarios, or something else.
We can put Throughput into the formula because Little’s Law assumes a stable system. Throughput is the departure rate and in a stable system it is the same as the arrival rate of Little’s original formula. An example of Throughput is five user stories per week.
Lead Time is the elapsed time an item spends in the system. For example if it takes 20 days for a user story to go through the system the Lead Time on that item was 20 days. The formula works for both “order lead time” – measured from when the customer orders the work – and “engineering lead time” – measured from when the work starts on the item.
In some ways it doesn’t matter what your actual numbers are. As Dave White pointed out:
The power of Little’s Law to Kanban teams is not its ability to predict WIP, Thoughput or Leadtime. The true power lies in its ability to influence team behavior with its underlying assumptions.
In other words, if you want to:
- increase Throughput then limit WIP
- speed up the process, i.e. reduce Lead Time, then once again limit the WIP
Bit of a theme there.
Frank Vega has a nice explanation of how Little’s Law works. I like the diagram of water tanks in his post Little’s Law: Isn’t it a Linear Relationship.
What about Cycle Time?
I have deliberately avoided talking about Cycle Time. Some people do factor Cycle Time into Little’s Law, but it is a bit of a minefield so I’ll leave that for a subsequent post.
References
Vega, F. (2012, 7 September). Little’s Law: Isn’t it a Linear Relationship. VISS.
White, D. (2012, 11 December). Little’s Law – It’s not about the numbers. Agile Ramblings.
Very interesting article, Steven! I haven’t heard about Little’s law till now. Kanban is a great, simple methodology that is applicable to every industry. Here’s something I wrote for its implementation in law (http://bit.ly/24SJrYf). Would love to hear your opinion!
Regards!
I’m glad you liked the article. The application of Kanban to Law is fascinating. And I appreciate the link to New Zealand … being a Kiwi myself.
THANKS A LOT OF, VERY INTERESTING
Basic is effective . . I find your article such lean, straight, and easy to understand . . Huge thanks Steven !!
“if you want to:
* increase Throughput then limit WIP”
That doesn’t make sense from algebraic point of view. WIP and Throughput are proportional.
For example:
LT = 1 week
WIP = 5 items
Throughput = 5 items / week
and increasing WIP = 10 items
Throughput = 10 items / week
So increasing WIP increases the throughput.
But in practice increasing a workload will not make a team more productive. I think that Little’s Law can be used to prove that increasing the average amount of work in progress (WIP) has the effect of increasing the average time it takes for each work item to be completed (Lead Time). And Throughput in a stable system stays the same (while WIP and Lead Time can influence each other).
Very good point Maciej. Thanks for sharing.
Throughput can only be increased by increasing WIP if there is spare capacity in the system. If you increase WIP to 10 items in a system that is running optimal with 5, then either you have to double the capacity of the system orwill end up with a Lead Time of two weeks instead of one.
I do not dispute Little’s Law as applied to queues but I cannot make sense of how it is being applied in Operations Management by the authors of “Factory Physics”. Firstly, Little’s Law applies to a stable system ie arrival rate = departure rate. Production lines are never stable. Secondly, as Maciej Falski mentions above, the formula does not make sense. By right WIP should equal CT / TH. I suspect that Little’s Law is being abused by so called consultants who, in trying to create a fad, are peddling “Factory Physics” to unsuspecting managers. I challenge anyone to prove that this so called “Factory Physics” has actually benefited their production processes.
When looking at systems that produce software, throughput is really determined by “capability”. Changing WIP will not change the capability of your system (team). Instead, increasing WIP will simply increase the wait time, or time from start to finish of each unit of work.
So if you have a team that can reliably complete 30 story points per week, then if you give them 60 story points to complete it will take two weeks to complete them all. That’s easy.
It gets a little harder to see if you measure units of work as “projects”. If your team can reliably complete 1 project per month, giving them 4 projects to work on simultaneously will not get projects done any faster. If they work on one project at a time it will take 1 month to get the first one done and 4 months to complete them all. If they work on all 4 simultaneously and equally they will have nothing done at the end of one month, and after 4 months all 4 will suddenly be completed. This is the essence of agile. By completing one in a month you are actually adding value sooner.
John, i have to disagree based on experience the example of 4 projects simultaneously will not finish in 4months. That would be a best case scenario assuming no resources or people are shared or dependent. Even then I would be shocked. The point is reducing WIP allows people, and in your example the organization, to focus on delivering fewer goals instead of context switching and waiting for other dependencies from becoming free. Take another guess on when the 4 simultaneous projects will finish.
Steven, great article.
I have a question if you or any member can answer.
When you are trying to work out a WIP for a year input, do you use the total number of calendar days or do you use the working days available to you?
So would it be 365 or 261?
I am considering that we could not induct a product over a weekend as there is no work planned for these days.
Hope you cam help.
Regards and Thanks,
Chris.