Little’s Law

Little’s law was first published in 1954. It wasn’t proven true until 1961 and the proof was simplified in 1972. This just about pre-dates iterative development methods and certainly pre-dates the Agile manifesto (2001). It’s from the same period as Toyota’s production system which gave us several great concepts (thank you Mr Ohno). Unlike these others, Little’s law is not very well known, but it is at work every day on your Jira boards. So what is it?

Let’s start with some notions you might already be familiar with. These are measures or metrics we encounter in our work.

Lead time

The average time it takes new items of work to enter and then leave the system. Items of work can be issues or stories from a work tracking tool (e.g. Jira). What counts as entering and leaving the system is ambiguous but the important thing is to be consistent. Decide when a work item is “started” and when it’s “done” (or cancelled), and make sure it’s automatically measurable.

Including everything in the backlog has some interesting and potentially positive consequences. How long do issues or stories sit in your squads backlog before moving to a sprint or being marked as “won’t do”? If “started” is defined as when an item of work moves in to a sprint then you may want a separate definition of Lead time for items in the backlog.

It should be noted that Cycle time, Takt Time and Wait time are other metrics that are often used when describing systems of work, while we don’t discuss them here it’s important to know that they are not the same as Lead time.

Throughput

Throughput is items of work done per period of time. To put it another way, Throughput is the average delivery rate and could be expressed as, for example, 3 items a week. It might take most of the week to do one of the items and then only a few hours for the other 2 items of work. Little’s law doesn’t care about variability, just the average.

WIP (Work in progress)

Number of items of work in the system. The definition of being in the system must be the same as the one used for Lead Time. If the clock is ticking for items in the backlog then those items count towards the WIP total as well. Little’s law assumes that new items of work are arriving at the same rate that they being done (this is a property of something called a stationary process). In reality this is unlikely to be true but you can take the average over the same period of time used to calculate the Throughput.

So with those terms defined, what is Little’s law.

Lead Time = WIP/Throughput

It’s important to remember that these are all average values. In most cases some items of work will be high priority and shoot though the system more quickly, this won’t effect the averages. The other constraint is that any work items that enter the system must be counted as leaving the system even if they are cancelled. If they are not counted then the values for Work In Progress and Throughput will become increasingly incorrect. The more variation in the values used, the lower the accuracy of the metric being calculated.

We can now use Little’s Law to indicate that increasing the amount of Work In Progress has the effect of increasing the Lead time for each new work item to be completed.

Examples

If there are 100 items in progress (the backlog and the current sprint) and the Throughput is on average 20 items a week (for a 5 day week) then the Lead time for new items will be 5 weeks. This assumes new items of work are arriving at a steady rate, equal to the Throughput. If new items are arriving at a faster or slower rate then the Work In Progress count will gradually change and the Lead time will increase or decrease respectively for those new items.

A high priority task can jump the queue and could be done more quickly but everything else sat in the queue will be delayed. Little’s law will be preserved.

Let’s suppose a new feature comes along, an epic is created and 50 new work items enter the backlog. If the Throughput remains constant at 20 items a week, the Lead time for subsequent new items is going to increase to 7.5 weeks. Assuming the priorities mean no queue jumping, you will know when the last work item of the new feature is likely to be done.

Story points

Little’s law will continue to work even if you start to measure story points instead of work items. This potentially offers a big improvement as not all work items take an equal amount of time to complete. For a stable team that can point work items predictably, individual story points will take a similar amount of time to complete.

Little’s law can handle the differences in work items (if there are enough of them) as it relies on averages but this means a lower accuracy for predictions. With meaningful story points, the accuracy of predictions can be improved.

Leveraging Little’s Law

If you read my last post on Leading and Lagging indicators then you should be able to identify that Lead time and Throughput are lagging indicators. They are easy to measure and quantify the current situation. Work in progress is the only leading indicator, it can be changed today and provides insight in to the future.

It’s possible to prioritise an item of work and get it done quickly but that doesn’t affect the overall Lead time. Using Little’s law we know that we can reduce the overall Lead time by working on less stuff or increasing throughput. Which is easier, do you think?