Applying Little's Law in Agile Games

Have you ever used Little's Law to explain that lower WiP (work in progress) limits lead to shorter cycle times? Ever tried to illustrate Little's Law in an Agile game and found it doesn't hold? Then read this blog to discover that it is exactly true in Agile games and how it really works. Some time ago I gave a kanban workshop. Part of the workshop was a game of folding paper airplanes to illustrate flow. To illustrate Little's Law we determined the throughput, cycle time and work in progress. To my surprise the law didn't hold. Not even close. In this blog I want to share the insight into why it does work!

Introduction

It is well known that the average number of items in progress is proportional to the average cycle time of completed work items. The proportionality is the average input rate (or throughput rate) of work items. This relation is known as Little's Law. It was discovered by Little in the 1960s and has found many applications. In kanban teams this relationship is often used to qualitatively argue that it is favourable for flow to have not too much work in parallel. To this end WiP (work in progress) limits are introduced. The smaller the WiP the smaller the average cycle time which means better flow. A surprise to me was that it is exactly true and it remains true under very relaxed conditions.

Little's Law

In mathematical form the law is often stated as: (1) [ bar{N} = lambda bar{W} ] Here ( bar{N} ) is the average number of work items in progress at a certain time, and ( bar{W} ) is the average cycle time. ( lambda ) is the average input rate (new work items per unit of time). In stable systems this also equals the average throughput. In this case Little's Law is often (re)stated as (2) [ frac{mathrm{Work, in, progress}}{mathrm{Throughput}} = mathrm{Cycle Time} ]

Conditions

In practise one considers Little's Law over a finite period of time, e.g. 6 months, 5 sprints, 3 rounds in an Agile game. Also in practise, teams work on backlog items which are discrete items. After the work is done this results in a new product increment. Under the following conditions (1) is exact:

• The system is observed over a finite period of time,
• The system is a queueing system.

A queuing system is a system that consists of discrete items which arrive at a certain rate, receive service after which they depart. Examples of a queueing system. An agile team works on backlog items. A kanban team that works on production incidents. A scrum team.

Agile Game

An often used game for explaining the importance of flow to team is the game of folding paper airplanes. Many forms of this games exist. See e.g. [Heintz11]. For this blog's purpose consider a team that folds air planes. The backlog is a stack of white paper. 3 Rounds of folding are done. Airplanes that are folded and fly at least 2 meters are considered done. At the end of each round we will collect the following metrics:

• number of completed airplanes
• number of airplanes in progress and not yet finished.

The result of the the 3 rounds are shown at the right. At the end of round 1 Team A completed 3 airplanes and having 8 unfinished airplanes. Likewise, Team B finished 4 airplanes in round 3 giving a total of 12 finished airplanes and having 6 unfinished airplanes in progress. The cycle time are got by writing the round number of the sheet of paper when starting to fold the airplane. When done, write the round number of the paper. The cycle time for one airplanes is got by subtracting the two and adding 1.

Calculating Little's Law

The way I was always calculating the number for work in progress, throughput and cycle time has been

1. averaging cycle time for all completed airplanes,
2. averaging the throughput over all rounds,
3. averaging the work in progress over all rounds.

When calculated at the end of round 3, for Team A this amounts to:

• Average work in progress = (8+6+2)/3 = 16/3,
• Average throughput = 10 (completed airplanes)/3 = 10/3,
• Average cycle time = 22/10 = 11/5

Using (2) above we get: 16/3 / (10/3) = 8/5. This is not equal to the average cycle time of 11/5. Not even close. How come?

The Truth

The interpretation of work in progress, throughput and cycle time I got from working with cumulative flow diagrams. There are many resources explaining these, see e.g. [Vega2011]. The key to the correct interpretation is choosing the time interval for which to measure the quantities ( bar{W} ), ( lambda ), and ( bar{W} ). Second, using the input rate instead of the throughput. Third, at the end of the time period include the unfinished items. Last, in calculating ( bar{N} ) consider all items that went through the system. When we reinterpret the results for teams A and B we get Team A

• Average work in progress In round 1 3 airplanes were completed and left 8 unfinished; a total of 11 for work in progress (11 airplanes picked up as work) In round 2 the team completed 2 airplanes and have 6 unfinished; a total of 8 In round 3 the team finished an additional 5 airplanes and left 2 uncompleted; a total of 7 When measured over 3 rounds an average of (11+8+7)/3 = 26/3
• Average input rate Using the input rate: In round 1 the team picked up 11 new airplanes In round 2 the team picked up no additional airplanes In round 3 one new airplanes was picked up. An average input rate of (11+0+1)/3 = 4 airplanes per round
• Average cycle time At the end of the third round 2 airplanes are left in progress; one taken up in the third round having a waiting time of 1 and one left from the first round having waiting time of 3 rounds. A total waiting time of 22 + 3 + 1 = 26 rounds. Averaging over 12 airplanes we have an average cycle time of 26/12 = 13/6 rounds per airplane.

Dividing the average work in progress by the average input rate we get 26/3 divided by 4 = 26/12(!). This is exactly equal to the calculated average cycle time! Team B In a similar manner the reinterpreted results for team B are:

• Average work in progress = (13+14+10)/3 = 37/3 airplanes,
• Average input rate = (13+2+3)/3 = 6 airplanes per round,
• Average cycle time = (27 (completed) + 10 (unfinished))/18 (airplanes) = 37/18 rounds per airplane

Again, dividing the average work in progress by the average input rate we get 37/18 rounds per airplane, which again is exactly equal to the average cycle time or waiting time! Note: the cycle time of 10 days is built up by (a) 1 airplane from round 1 (cycle time of 3), 2 airplanes picked up in round 2 (total of 4 rounds), 3 airplanes picked up in round 3 (total of 3 rounds).

What About Cumulative Flow Diagrams?

Now that we understand how to calculate the quantities in Little's Law, we go back to cumulative flow diagrams. How come Little's Law works in this case. In the case of teams that have collected data on cycle time, work in progress and throughput Little's Law work when done as explained in the section 'Calculating Little's Law' because:

1. the teams are kept stable by having WiP limits on the left most column ("To Do"); then the throughput is more or less equal to the input rate,
2. the team has completed a fairly large amount of work items in which case the waiting time of unfinished work items can be neglected,
3. when measured over the (large part of the) value creation process, the completed items per time period can often be neglected in the calculation of the average work in progress.

Summary

Little's Law (1) holds under the conditions that (a) the system considered is a queueing system and (b) the observation or measurements are done over a finite time interval. It then holds independently of the stationaryness of the probability distributions, queuing discipline, emptiness of the system at the start and end of the time interval. Calculate the quantities ( bar{N} ), ( lambda ), and ( bar{W} ) as follows:

• Average work in progress ( bar{N} ) For each time interval considered count the total amount of work in the system and add any items completed in that time interval.
• Average cycle time ( bar{W} ) Sum the cycle times for all completed items and include the waiting time for unfinished items and divide by the total number of items.
• Average input rate ( lambda ) Add the total number of items that entered the system and divide by the total number of time intervals.

References

[Little61] Little, J. D. C. 1961. A proof for the queuing formula: L = ãW . Oper. Res. 9(3) 383–387. [Heintz11] John Heintz, June 2011, Agile Airplane Game, GistLabs, https://gistlabs.com/2011/06/agile-airplane-game/ [Vega11] Vega Information System Services, Inc., September 2011, Basics of Reading Cumulative Flow Diagrams, https://www.vissinc.com/2011/09/29/basics-of-reading-cumulative-flow-diagrams/