How does Viz use Little's Law?
- Last updated
- Save as PDF
Last Updated: | Applicable Viz Versions: All
Answer
If you've read much Lean literature, you have probably come across Little's Law. Little's Law Formula is a theorem by Dr. John Little which shows the connection between the average arrival rate of a queue, the average number of items in the queue and the average amount of time an item spent in the queue.
Expressed algebraically, the law is:
L = λW
Where,
L is the average number of units in the system
W is the average mean time spent by a unit in the system
1/λ is the average number of items arriving per unit of time
This original formula is written in terms of the arrival rate of work.
In knowledge work, however, we usually see Little’s Law formula written in terms of the departure (throughput) rate:
Flow Time = WIP/Throughput
Where,
Flow Time = average time an item takes to Flow through the system
Work-in-Progress (WIP) = average amount of work started but not finished
Throughput = average number of items completed over a period of time
For the purposes of this FAQ, we will use the term Flow Velocity® to mean Throughput.
Little’s Law is a relationship of averages. The gist of Little’s Law is that — on average — the more items that are worked on during the same time interval, the longer it will take to finish those items on average. Dr. Little demonstrated that the three key Flow Metrics — Flow Time, WIP (or Flow Load® in Planview Viz), and throughput (or Flow Velocity in Viz) — have a relationship, and why changing any one of these Flow Metric can impact the others.
Looking at Little’s Law from a Flow Velocity perspective brings along with it some assumptions. All metrics are based on assumptions and Little's Law is no different. All you have to do to discredit a metric is to question the assumptions. In order for your metrics to be taken seriously, carefully consider and identify the assumptions in place.
It’s All About the Assumptions
The true power of Little’s Law is not in calculating the math, but in understanding the assumptions necessary for the law to work in the first place. Using Little’s Law to calculate a quantitative forecast is an incorrect application of the law. Little’s Law is about examining what happened in the past — not about making deterministic predictions about the future. One cannot predict which of the law’s assumptions will be violated in the future and how many times. Each violation of an assumption invalidates the correctness of the law.
Planview Viz checks system stability based on Little’s Law assumptions. For example, Viz compares the average arrival rate to the average departure rate and checks the average age of WIP to see if it’s increasing or decreasing. The resulting insights appear in the Diagnostic Insights panel.
Using Little's Law to continuously evaluate how well you're tracking to the assumptions provides an advantage for your organization to improve its Flow. If Flow Metrics start to skew (average Flow Time for example) then you have a leading indicator to utilize for improvement.
Planview Viz Flow Metrics and insights will help you see when you start to deviate from stable and predictable Flow.
Assumptions about the software delivery workflow process necessary for validity of Little's Law (based on Dan Vacanti’s excellent work writing and speaking about Little’s Law:
- The average input or arrival rate should equal the average output or departure rate.
- All work that is started will eventually be completed.
- The amount of WIP should be roughly the same at the beginning and at the end of the time interval chosen for the calculation.
- The average age of the WIP is neither increasing nor decreasing.
- Flow Time, WIP and Flow Velocity must all be measured using consistent units.
The first two assumptions comprise a notion known as Conservation of Flow. Assumptions three and four address system stability. Assumption number five is necessary for the math and any corresponding analysis to be correct.
Let’s explore these assumptions.
Assumption #1: The average arrival rate should equal the average departure rate.
When the arrival rate of work is equal to the departure rate of work, it means that teams can finish work before starting new work, enabling a smooth Flow of work through the value stream process. Smooth workflow means less stagnant work and fewer bottlenecks. This is the goal of pull systems and where saying “no” comes into play. Allowing teams to pull work into their work queue based on their available capacity increases the likelihood that the work will have the team’s full attention and be processed faster.
Assumption #2: All work that is started will eventually be completed.
This assumption is all about commitment. Committed work means that you have everything you need to do the work. That you have the capability, the approval, the skills, and the money to do the work. Once work passes the line of commitment, the understanding is that it will be worked on and delivered. Ideally, at this point you could let your customer know the probable timeframe for when the committed item will be delivered.
When teams have high WIP compared to capacity, some work will be neglected and delayed (because teams are busy working on other things), and the likelihood increases that some WIP may be canceled. Teams should be relentless in finishing work before starting new work.
Assumption #3: The amount of WIP is roughly the same at the beginning and the end of the time interval.
Teams that allow WIP to increase over time may notice that Little's Law doesn't work well for them because they're breaking this assumption. Similarly, if a lot of WIP is suddenly removed, the math will break.
Assumption #4: The average age of the WIP is neither increasing nor decreasing.
When average Flow Time is growing or declining, it means that some items complete faster than other items. This jeopardizes your predictability. It’s like robbing Peter to pay Paul, in that you are stealing Flow Time from other work items that were already in progress. When work items are “born-in-doing”, they skip over older WIP. When that older WIP moves to done, the Flow Time will be longer than it normally would have because it sat idle and aged. The result is less confidence in the average Flow Time the team thought they were capable of achieving because past metrics did not include aging WIP.
Also, if the work items that were robbed by Paul see continued neglect, they may end up canceled if they are no longer considered valuable, perhaps because the window of time to realize value has passed. Time matters. When work items fail to complete the process, any effort spent on processing them through the value stream equates to waste.
Assumption #5: Flow Time, WIP and Flow Velocity must all be measured using consistent units
This assumption is necessary for the math to be correct. Consistent units of measure are required. This is why story points don’t compute when using Flow Metrics. Because the units of measure for Flow Time is actual time (days/weeks/months), the throughput measure must also be the same (days/weeks/months).