The Iron Triangle of Flow
A gentle introduction to Little's Law
Note: This post was originally published in Sept 2022. It is very consistent with how Little’s Law is presented in Lean/Agile circles. At the time I more or less convinced this was correct. I no longer believe this is true. I am leaving this here as a record of my past beliefs, but I recommend you read our latest series on Little’s Law, starting with “The Many Faces of Little’s Law” instead.
Little's Law is a fundamental mathematical result from queueing theory.
Queueing theory analyzes systems where discrete items enter and leave over time, focusing on key aspects of the system's population dynamics—how long items spend in the system, how the population size evolves over time, and the factors influencing these behaviors.
Little's Law establishes a relationship between three measurements made periodically by observing the items moving through the system over a continuous observation window:
The rate at which items arrive (the arrival rate) and leave (departure rate)
The time items spend in the queue and
The number of items in the queue.
If you want to understand how to allow work to flow efficiently through a queueing system, you need to be able to measure and manage these key things.
Little's law states that there is a precise relationship between the three quantities above under certain conditions and mathematically proves the conditions under which this relationship holds.
It implies that when these conditions hold, knowing any two of the above quantities completely determines the third one.
Very few mathematically provable theorems apply to software development, but this is an ironclad one that we can almost think of as Newton's Law for our field. Hence, it's worth understanding it well.
So, let's dive deeper.
Statement of the law
If you’ve encountered Little’s Law before in a software development context, you’ve likely seen it as an equation relating Cycle Time, Wip, and Throughput, as shown in Figure 1 below.
However, the equation holds only when you pay careful attention to the definitions of each of these terms for the system you are observing and also under specific assumptions about the conditions under which the measurement is done.
In the following few sections, however, we'll be quite informal in how we define these terms and look at some examples to understand what Little’s Law is saying intuitively.
Parsing the Law
First, let us look at the relationship between the measurements.
Note that it is a relationship between averages. So, the law does not say anything about the cycle time of any individual item or the actual throughput of the system but just about the average values of these properties for the queue over a sufficiently long measurement period.
This is important to remember, particularly in light of how the law might be written out in popular expositions (without those pesky average symbols).
Now, let's look at the conditions.
The average arrival rate is equal to the average departure rate (throughput)
All items that enter the system will eventually exit the system.
The number of items is roughly the same at the beginning and end of the measurement period.
The average age of items in the system is neither increasing nor decreasing.
The conditions have nothing to do with the system's internal structure, how long any given item takes to process, or what happens to the items as they move through the system. The system is a black box, and the law applies as long as the conditions hold.
The conditions are process-agnostic and relatively simple to measure based on the average behavior observed over time. That we can characterize the behavior of an arbitrary system without knowing much about its details is truly a non-intuitive result!
An example
Let's take a simple example to illustrate things. Assume we have a Scrum team operating in 2-week sprints. They typically finish most items they signed up for during the sprint, but sometimes, items spill over and get done in sprints later than the ones they initially started in.
Let's start by examining this team over a 30-day measurement period, which is about two sprints' worth of work. We also have to choose a fixed unit of measurement to apply Little's Law and a day for this.
Over the 30 days, the team finished ten stories. The average throughput is, therefore, 1/3 stories per day. This is the first key component of Little's Law. It measures the rate at which the team finishes work (not how much work the team finished).
The second quantity is the average daily WIP. This is the average number of stories in progress for each day in the 30-day period. This number of items on any day can increase or decrease as stories start and finish during the period. In this example, let’s say the average is 5.
Then, Little's Law says that assuming the rest of the conditions of the theorem were satisfied, each story should expect to spend an average of 5/(1/3) or 15 days in the process. This is the expected average cycle time for the process during this measurement period per Little's Law.
If we actually measure the average cycle time and it turns out to be much more or much less than this expected value, then we know for sure that at least one of the conditions must have been violated. In practice, we will usually find this to be the case.
As a second example, let's say the team finished the same ten stories in 30 days, but the average daily WIP was 8, then the average expected cycle time is now 24 days (8/(1/3)).
So, given that we are completing stories at the same rate, if you have more stories in progress at any time, you should expect each story to take longer on average.
Interpreting Little's Law
In both cases, what Little's Law says seems obvious and intuitive. This is the behavior we would expect to see if, say, we were standing in a long checkout line at the grocery store - you can look at how often people are leaving with their groceries and look at the number of people ahead of you in the line and try and get a quick estimate for how long you would have to wait to get checked out. This is easy to see in a single checkout line moving efficiently.
What is truly non-intuitive is that this same, simple formula can be applied even if you looked at all the people waiting in line across all checkout lines in the grocery store, no matter how many lines there were and no matter how fast any single checkout line was moving, or how long any given person took to get checked out provided the whole checkout process is operating efficiently.
Little's Law tells us what conditions have to hold across the whole system for this more complex system to behave like a single checkout line.
What is even more exciting is that the conditions are not particularly complicated or esoteric conditions to check.
This is the power and beauty of Little's Law. If we can ensure the conditions of Little's Law apply, we just need to periodically make a few easy measurements of the process without knowing much else about how work is done to manage the flow of work.
Of course, the million-dollar question is, do real-world software delivery processes meet those conditions?
And the answer is a definite no.
To achieve flow, we have to carefully manage many different aspects of how we measure and manage work in the system. However, Little’s Law gives us one of the essential tools we can employ to reason rigorously about how to achieve this.
We will delve into these nuances in subsequent posts in this series.
Acknowledgments
This post draws heavily from Dan Vacanti's published work for inspiration. The definition of Little's Law is based on the version in his book Actionable Agile Metrics for Predictability. I highly recommend that book for its accessible explanation of flow theories that gives you the key ideas without getting too technical.
Little’s Law is foundational to analyzing flow through a network of queues. Significant prior research and applications exist in this area, which we will explore in the context of software development. If you are interested in a much more technical read showing how these ideas are applied in the design of hardware architectures, for example, Prof Ed Lazowska's textbook, which is available online, is a fantastic resource.
Many thanks to Priya Mukundan, Bryan Finster, and Ron Lichty for their edits and comments on the versions of this post.
Footnotes:
A set of technical assumptions about the steady-state behavior of a stochastic process is needed to support applying Little's Law. The most important are sufficiently long intervals for measurements and consistent periods and units for measurements. We are using days as the unit here and choosing to describe the law in terms of daily averages for a more straightforward exposition. Still, the general form of the law can be applied using any consistent set of units.
These conditions are necessary primarily because the law is phrased regarding system response time. This means we need to account for end effects: when observing arrivals and departures over a fixed interval, we need to account for the arrivals that came before the start or end of the interval and have not departed.
A version of this law applies unconditionally if we express it in terms of a quantity called residence time that ignores end effects. The conditions of Little's Law may be viewed as those that make residence time identical to response time. In practice, many operational analysis tools use residence time as the key measurement, assuming that the measurement interval is much larger than the average residence time. These subtleties are essential to understanding how to use Little’s Law in an operational sense, and we will examine these in more detail in the next post in the series.