Little’s Law Applied in Agile & Knowledge Work — Part 1 of 2

The science behind limiting work in process and why it is done in Agile & knowledge work

Leo Inthapichai
Oct 15, 2020 · 5 min read

Start less, to finish more.

If the goal is to complete work sooner, pulling in more work is the worst course of action to take.

There’s a mathematical proof which shows the more work there is in a stable system, the longer it will take to complete each unit of work. This is essentially Little’s law in layman’s terms. Little’s law is a powerful formula which establishes a simple relationship between cycle time, work in process and throughput, in a stable system.

Cycle Time = WIP / Throughput

  • Cycle time: the amount of time on average an item spends in the system. An item can be anything from user stories in a development pipeline, coffee orders at a cafe to patients in a hospital system
  • WIP: work in process — the average number of items in the system at any given time
  • Throughput: the rate at which items move through (or are processed by) the system on average
  • In a stable system, items enter and exit the system at the same rate. All items that enter the system, will also exit it (that is, none are lost within the system)

We see Little’s law in action every day in all types of scenarios:

  • The more customers there are in line (WIP), the longer each customer has to wait (cycle time)
  • The more orders being processed (WIP), the longer it takes to fulfil each order (cycle time)
  • The slower the service (throughput), the longer a customer waits (cycle time)
  • The more user stories a development team works on concurrently (WIP), the longer it takes to finish each story (cycle time)

Do you notice a recurring theme in the above examples? They’re intentionally phrased to show the impact of the other 2 variables on cycle time. One of the principles of Agile is to deliver working software early and frequently. Little’s law states that there are 2 levers to pull to achieve this — either increase throughput or reduce WIP. This is why limiting WIP is practiced in Kanban (by explicitly setting WIP limits) and SCRUM (through Sprints).

We’ll touch more on how to apply Little’s law in Agile and knowledge based environments in Part 2. For now, let’s see Little’s law in action in a simple scenario.

Consider a 2 person operation for a takeaway coffee cart business. The system looks like this:

John takes the orders from the customers → Elizabeth makes the coffee → Customers collect their coffee

In this system, the input is a coffee order and the output is a coffee. John and Elizabeth can serve their customers at a rate of 6 coffees per minute (throughput). On average, there are 12 coffee orders being processed at any given time (WIP). Little’s law tells us that the average time a customer needs to wait for their coffee (cycle time) is:

Cycle time = 12 coffees / 6 coffees per minute = 2 minutes

After a while, John and Elizabeth decide to look at ways to differentiate themselves from the competition. They’ve identified their main clientele as busy people who need to grab a coffee quickly and decide to provide a guarantee that each customer will get their coffee within 1 minute of placing the order. We’ll see they have 2 ways of achieving this — by increasing throughput or limiting WIP.

Option #1 Increase throughput — John and Elizabeth identified that their coffee machine is the bottleneck in the process limiting the number of coffees they can churn out, so they decide to buy a second machine to run alongside the existing one. Throughput doubles from 6 coffees per minute to to 12. This has the effect of reducing cycle time to 1 minute:

Cycle time = 12 coffees / 12 coffees per minute = 1 minute

(Note in the graphic below, throughput has doubled — coffees are passing through the system at twice the speed, and as a result each customer receives their coffee sooner)

Option #2 Limit WIP — Rather than spending money purchasing another machine, John and Elizabeth tweak their process to limit the number of coffees in process to 6. John can take orders as fast as they come, as long as there are 6 or less orders in the process. After that, he’ll wait for Elizabeth to finish making a coffee before taking any more orders. On average, there’ll be 6 coffees in the process at any given time. This has the effect of reducing cycle time to 1 minute, and they achieve their guarantee:

Cycle time = 6 coffees / 6 coffees per minute = 1 minute

(Note in the graphic below, throughput has not changed, but each customer is still getting their coffee sooner because WIP has reduced)

Little’s law tells us that cycle time can be reduced by either increasing throughput or reducing WIP. Increasing throughput though, usually requires making fundamental changes to the process, such as buying another coffee machine (which costs money) and/or making incremental improvements over a long period (upskilling and coaching staff, continuous improvement through retrospectives, etc). Limiting the WIP can be achieved by tweaking existing processes and will have an immediate effect on cycle time at no cost.

In Part 2, we’ll see how to limit WIP in Agile and knowledge work and the benefits of doing so.

The Startup

Get smarter at building your thing. Join The Startup’s +730K followers.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +730K followers.

Leo Inthapichai

Written by

I enjoy learning about and teaching Agile — above all, seeing it put to good use.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +730K followers.