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 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
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
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.
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.