Agile Transformation

Why Little's Law Works...Always Pieter Rijken 11 Jul, 2014

The much used relation between average cycle time, average total work and input rate (or throughput) is known as Little's Law. It is often used to argue that it is a good thing to work on less items at the same time (as a team or as an individual) and thus lowering the average cycle time. In this blog I will discuss the less known generalisation of Little's Law giving an almost unlimited number of additional relation. The only limit is your imagination.
I will show relations for the average 'Total Operational Cost in the system' and for the average 'Just-in-Timeness'. First I will describe some rather straightforward generalisations and in the third part some more complex variations on Little's Law.## Little's Law Variations

As I showed in the previous blogs (Applying Little's Law in Agile Games and Why Little's Law Works...Always) Little's Law in fact states that measuring the total area from left-to-right equals summing it from top-to-bottom.
Once we realise this, it is easy to see some straightforward generalisations which are well-known. I'll mention them here briefly without ging into too much details. *Subsystem* Suppose a system that consists of 1 or more subsystems, e.g. in a kanban system consisting of 3 columns we can identify the subsystems corresponding to:*Work Item Type* Until now I assumed only 1 type of work items. In practise teams deal with more than one different work item types. Examples include class of service lanes, user stories, and production incidents. Again, by colouring the various work item type differently we see that Little's Law applies to each individual work item type.
In the example on the right, we have coloured user stories ('yellow') and production incidents ('red'). Again, Little's Law applies to both the red and yellow areas separately.
Doing the math we se that for 'user stories' (yellow area):*Expedite Items* Finally, consider items that enter and spend time in an 'expedite' lane. In Kanban an expedite lane is used for items that need special priority. Usually the policy for handling such items are that (a) there can be at most 1 such item in the system at any time, (b) the team stop working on anything but on this item so that it is completed as fast as possible, (c) they have priority over anything else, and (d) they may violate any WiP limits.
Colouring any work items blue that spend time in the expedite lane we can apply Little's Law to the expedite lane as well.
An example of the colouring is shown in the figure on the right. I leave the calculation to the reader.## 3D

We can even further extend Little's Law. Until now I have considered only 'flat' areas.
The extension is that we can give each cell a certain height. See the figure to the right. A variation on Little's Law follows once we realise that measuring the volume from left-to-right is the same as calculating it from top-to-bottom. Instead of measuring areas we measure volumes instead.
The only catch here is that in order to write down Little's Law we need to give a sensible interpretation to the 'horizontal' sum of the numbers and a sensible interpretation to the 'vertical' sum of the numbers. In case of a height of '1' these are just 'Waiting Time' (W) and 'Number of items in the system' (N) respectively.
A more detailed, precise, and mathematical formulation can be found in the paper by Little himself: see section 3.2 in [Lit11].## Some Applications of 3D-Little's Law

*Value* As a warming-up exercise consider as the height the (business) value of an item. Call this value 'V'. Every work item will have its own specific value.
\( \overline{\mathrm{Value}} = \lambda \overline{V W} \)
The interpretation of this relation is that the '*average (business) value of unfinished work in the system at any time*' is equal to the average input rate multiplied by the '*average of the product of cycle time and value*'.
Teams may ant to minimise this while at the same time maximising the value output rate. *Total Operational Cost* As the next example let's take as the height for the cells a sequence of numbers 1, 2, 3, .... An example is shown in the figures below. What are the interpretations in this case?
Suppose we have a work item that has an operational cost of 1 per day. Then the sequence 1, 2, 3, ... gives the total cost to date. At day 3, the total cost is 3 times 1 which is the third number in the sequence. The 'vertical' sum is just the '*Total Cost of unfinished work* in the system.
For the interpretation of the 'horizontal' sum we need to add the numbers. For a work item that is in the system for 'n' days, the total is \(1+2+3+...+n\) which equals \(1/2 n (n+1)\). For 3 days this gives \(1+2+3=1/2 * 3 * 4 = 6\). Thus, the interpretation of the 'horizontal' sum is \(1/2 W (W+1)\) in which 'W' represents the waiting time of the item.
Putting this together gives an additional Little's Law of the form:
\( \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W(W + 1)} \)
where 'C' is the operational cost rate of a work item and \(\lambda\) is the (average) input rate. If instead of rounds in a game, the '*Total Cost in the system*' is measured at a time interval 'T' the formula slightly changes into
\( \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W\left(W + T\right)} \)
Teams may want to minimise this which gives an interesting optimisation problem is different work item types have different associated operational cost rates. How should the capacity of the be divided over the work items? This is a topic for another blog. *Just-in-Time* For a slightly more odd relation consider items that have a deadline associated with them. Denote the date and time of the deadline by 'D'. As the height choose the number of time units before or after the deadline the item is completed. Further, call 'T' the time that the team has taken up to work on the item. Then the team finishes work on this item at time \( T + W \), where 'W' represent the cycle time of the work item. In the picture on the left a work item is shown that is finished 2 days before the deadline. Notice that the height decreases as the deadline is approached. Since it is finished 2 time units before the deadline, the just-in-timeness is 2 at the completion time. The picture on the left shows a work item one time unit after the deadline and has an associated just-in-timeness of 1.
\( \overline{\mathrm{Just-in-Time}} = \frac{1}{2} \lambda \overline{|T+W-D|(|T+W-D| + 1)} \)
This example sounds like a very exotic one and not very useful. A team might want to look at what the best time is to start working on an item so as to minimise the above variable.## Conclusion

From our 'playing around' with the size of areas and volumes and realising that counting it in different ways (left-to-right and top-to-bottom) should give the same result I have been able to derive a new set of relations.
In this blog I have rederived well-known variations on Little's Law regarding subsystems and work items types. In addition I have derived new relations for the '*Average Total Operational Cost*', '*Average Value*', and '*Average Just-in-Timeness*'.
Together with the familiar Little's Law these give rise to interesting optimisation problems and may lead to practical guidelines for teams to create even more value.
I'm curious to hear about the variations that you can come up with! Let me know by posting them here.## References

[Lit11] John D.C. Little, "*Little’s Law as Viewed on Its 50th Anniversary*", 2011, Operations Research, Vol. 59 , No 3, pp. 536-549, https://www.informs.org/content/download/255808/2414681/file/little_paper.pdf

- first column (e.g. 'New') in 'red',
- second column (e.g. 'Doing') in 'yellow',
- third column (e.g. 'Done') in 'green'

- Average number in the system (N) = (6+5+4)/3 = 5 user stories,
- Average input rate (\(\lambda\) = 6/3 = 2 user stories per round,
- Average waiting time (W) = (3+3+3+3+2+1)/6 = 15/6 = 5/2 rounds.

Agile Transformation

Why Little's Law Works...Always Pieter Rijken 11 Jul, 2014

Agile Transformation

Applying Little's Law in Agile Games Pieter Rijken 07 Jul, 2014

Agile Transformation

Demonstration of the Exactness of Little's Law Pieter Rijken 23 Jan, 2016