Systems amenable to Little's Law looks like this
Inputs can be a discrete or continuous flow of work arriving for service in the System. The System is a general concept that defines the boundary for all the work activities that transform Inputs into Outputs. The Output is the same as the Input and can be referred to as Throughput.
There are two possible scenarios of this paradigm
- The System is performing a single cycle for a finite period of time
- The System is in Steady State performing a long rum of cycle
Little's Law is applicable when the system is in its steady state mode
- λ is the rate at which units of work arrive and in the steady-state mode, the rate at which units of work depart.
- L is the units of work in the system. This is the Work in Progress (WIP). This is the throughput rate.
- W is the time any unit of work spends in the system. This is the service time.
Little's Law says
L = λ × W
For software development systems like Kanban, which is production line-centric, Litle's Law tells us
- L = Average Work In Progress
- W = average time needed to complete the unit of work
- λ = average production rate of complete software components
- 1/λ is the cycle time for the work item.
There are two fundamental assumptions for Little's Law to work in the software development domain"
- The system is stable without major changes. The three variables involved do not change significantly while being observed.
- The units of measure used for the three variable are consistent.
The beauty of Little’s Law are the things that don't when applying the law. This makes Little's Law almost universal, not dependent on any specific domain - from the shop floor to Kanban development, the bank teller lines, to stocking grocery store shelves
- The Random distribution of the arrival and the departure speeds (the throughput) does not matter.Little’s Law holds if we have normally distributed variables (all three), exponentially distributed variables, or any other random distribution.
- The sequence of the work processing can be any order: First in First out, Last in First out, or any other or even a random sequence in your workflow. No matter what flow model, Little’s Law is valid to calculate the mean values of the variables. Depending on the work sequence, the fluctuation in throughput time may be much more in LiFo than in FiFo, but the mean value time of the workflow will be correct.
- Size of the observed loop does not matter.Little’s Law is valid f we''re modeling one team with a single input stream, or multiple teams working the entire project, or multiple project flows implementing the entire Program,
- Everything else you can think of: As long as the two conditions above hold true, Little’s Law is valid.
Back to the Steady State Condition
The relationships between the variables in Little’s Law only work in a steady state. Steady state is achieved when the arrival rate of work for the systems is the same as the departure rate of completed work from that system - on average over the long-term.
This means that throughput, arrival rate, and departure rate are the same.
Why Have WIP Limits?
In a System we want to model with Little's Law, setting a WIP limit helps establish a steady state condition. The WIP tells us where in the system there is a weakness. As an inverse problem, never getting close to the WIP limit tells us we are underutilizing the resources of the system. So an Upper and Lower WIP limit is needed to model the system to determine what the Throughput would be if the system were operating in a Steady State condition.
Kanban and Software Development
With the Steady State condition and it's Upper and Lower WIP limits, software develop creates a problem for applying Little's Law.
Software Development Projects Rarely Have a Steady State Condition
To use Little's Law for software development we need to know a few things first
- What is the process?
- What are the steps in the process?
- Do we have control over these steps?
- How do we modeling these steps in a way that allows us to calculate the independent variable of Little's Law?
If we can measure 2 of the 3 variables, L, λ, or W, we can calculate the third - assuming the system is in a steady state condition.
Of course, the first step in this calculation is to measure. But what if we're trying to decide what throughput is needed for some process in the future. And we don't have the measurement of a current steady-state system. That is we're planning for the future performance of the system to produce the outcomes of the software development processes NEEDED to meeet a business goal.
Then we have to Estimate what these measures need to be so the third variable of Little's Law can be Calculated
It has been suggested that with Little's Law No Estimates (#NoEstimates) can be applied. This is simply not true.
Achieving Steady State
On all software projects - unlike the Toyota car production line - demand for work fluctuates. So estimates are needed to produce numbers for this demand, rather than measuring the demand. Of course demand those estimates are derived from past performance in the domain of the software development processes, but they are Estimates all the same, rather than the steady state condition assumed by Little's Law.
There are two simple ways to establish steady state in a development system subject to Little's Law
- Reduce the demand for work to a level that will never breach the WIP limit. This is the ultimate control solution.
- Increase the throughput of the system to match the maximum demand. This provides the best performance since any level of demand can be met by increasing throughput.
One More Thing
For software development systems like Kanban, Little's Law can be a useful modeling tool if:
- Data is available for past performance that can be used to estimate future performance - this is called Reference Class Forecasting. This data can be used to assess the variables of Little's Laww to see if you have the right capacity for work compared to the arrival rate of that work. Or if the WIP limits are set right to provide the needed throughput for delivering the needed capabilities to the customer tpo meet the expected business value delivery.
- The system can be placed in a steady state condition and help in that condition for some period of time needed to forecast that the planned performance can be achieved to meet the business goals. These business goals can be Service Level Agreements, Release Plans, or any other date and cost driven needs of the business.
- But if you have no past performance data, then you'll need to make estimates of the possible values of the variables to meet these business goals.
But just a reminder - All Software Development project work, no matter the method, Kanban, Scrum, Traditional, requires making estimates about outcomes in the presence of uncertainty about future conditions.
There is no way out of this.
Anyone telling you there is, is not telling you the facts about the math of making decisions in the presence of uncertainty using Little's Law or any law for that matter.
Resources for Little's Law
- "A Distributional Form of Little's Law," Julian Keilson and Les Servi, MIT Operations Research Center, 1988
- "Estimating Average Production INtervals Using Inventory Measurements: Little's Law for Partially Observable Processes," Ardavan Nozari and Ward Whitt, Operations Research, Vol. 36, No. 2, Operations Research in Manufacturing (Mar. - Apr. 1988), 308-323.
- "Little’s Law assumptions: “But I still wanna use it!” The Goldilocks solution to sizing the system for non-steady-state dynamics," Alex Gilgur, Computer Measurement Group, 2013
- "Little's Law," John D. C. Little and Stephen C. Graves, MIT, in Building Intuition: Insights From Basic 81 Operations Management Models and Principles, 2008.
- "Little’s Law as Viewed on Its 50th Anniversary," John D. C. Little, Operations Research Vol. 59, No. 3, May–June 2011, pp. 536–549
