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.

**In The End**

For 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*. - 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 need of the business.

But just a reminder - All Software Development project work, no matter the method, Kanban, Scrum, Traditional requires making estimates about the future outcome in the presence of uncertainty about that future or the present conditions. There is no way out of this. Anyone telling you there is, is telling you a fib.

**Resources for Little's Law**

- "A Distributional Form of Little's Law," Julian Keilson and Les Servi, MIT Operations Reaearch 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

## Recent Comments