Little’s law applied in agile software development
Little’s law is a theorem in queueing theory by John Little. What it says is that long-term the average number (L) of customers in a stable system equals the long-term average effective arrival rate (λ) multiplied by the average time (W) that a customer spends in the system. As a mathematical formula it’s:
L = λ W
In simple words, there is a relationship between the average number of customers in a stable system, their arrival rate, and the average time in the system.
What has this to do with agile software development?
There are many queues in software development generally, not only in agile software development. There are technical queues implemented in software itself. Not implemented but still relevant, there are also queues of work items, requirements, support requests, bug, etc in the process of developing software.
In agile software development we want to deliver software at a constant and sustainable pace. To achieve this we can’t overload our system with work, as it otherwise will obviously not be sustainable. So let’s look for the equivalents of the average number of customers in the system, average arrival rate and the average time that a customer spends in the system: work in progress (WIP), throughput and lead time.
- WIP = average number of work items in process = L
- Throughput = average departure rate of work items = λ
- Lead Time = average time a work item spends in the process = W
You certainly have noticed that I’ve changed from average arrival rate in the definition by John Little to average departure rate. That’s ok, as in a stable system arrival rate should equal departure rate.
Looking at work in progress, throughput and lead time, experienced agilists immediately think of Kanban, some probably of Lean Development in general and a few maybe also of Scrum.
What insights do we get from Little’s law?
One of the things we try to achieve with agile software development is, to work efficient. In other words processing work in the best possible way with as little waste of time and effort as possible. To not get back to academic sentences again; after applying some basic maths to the formula above it will look like this:
W = L / λ
for better readability
Lead Time = WIP / Throughput
As we learned in school, Lead Time will increase when WIP (mathematically the numerator) increases or the throughput (in maths the denominator) decreases. With this Little’s Law delivers useful insights for systems in agile software development. Note; in that context we usually use the word team instead of system.
We limit work in progress (and focus) and with that shorten the lead time, meaning we deliver value faster. Knowing that can deliver even more value to a team, as this awareness may trigger a change in behavior.
What you also could get from Little’s Law is, that you see that the relationships between WIP, throughput and lead time doesn’t work as expected. In other words, you might learn that you don’t work with a stable system.
–
A few words about the relationship between WIP and Throughput. In a stable system with invariant type of work, according to Little’s Law this relationship is linear. The question is, how invariant work in software development is. That topic I’ll cover in a separate post.
Sources:
Leave a Reply