Home » Posts tagged 'little’s law'

# Tag Archives: little’s law

## Little’s Law – It’s not about the numbers

I was recently at the Kanban Leadership Retreat in San Diego, hanging out with a bunch of great people from the community and talking all about Kanban for three days.

This is an un-conference format event so we end up talking about whatever the group is interested in talking about, and one of the best sessions that we had (amongst a group of great sessions) was a session on Little’s Law that was hosted by Dan Vacanti (@danvacanti). Dan has been talking about Little’s Law at conferences for the last few months and the group was really interested in hearing this presentation as well as the interactive questions and answer that would happen throughout. It was during the interactive part of the session that “it” finally clicked for me!

Up until now, I didn’t understand why I would need to use Little’s law. I don’t want to use this blog post to describe Little’s Law and besides, Daniel’s presentation does an excellent job of that.

I’m really dumbing this down but in short (Sorry Dan), Little’s Law provides two things of interest for us Kanban practitioners:

1. allows us to derive one of three important Kanban metrics when any two of them are available to use in the calculation

2. allows us to understand/predict the impact of changes on one of those values to the other two

On the first point, for people running their work in kanban systems, normally all of the values are available if you’re managing your work well enough. Approx. Avg. Lead-time, Avg. Work In Progress, Avg. Throughput are relatively easily tracked or counted, and they can all be seen in a Cumulative Flow Diagram. Given I can observe all three in our system; I don’t need Little’s Law to help with that.

Note* – For planning purposes, we can use this relationship to understand what numbers

we might need in the future. Eg. Calculating required WIP based on an anticipated throughput and a proven capability (lead time) to establish resourcing levels

The second point is really interesting to us but is also where we stumble upon the gotcha and the false knowledge that often occurs on teams when they are using Little’s Law. It was in the interactive session that I finally had my epiphany around this second point! It isn’t (usually) about calculating the missing number or predicting changes in the numbers. It is about ensuring that you ** CAN** use Little’s Law at all!! That’s the tricky part and in my opinion, the really powerful thing I learned at KLRUS.

See, in order to use Little’s Law and have it work as you’d expect, there are a number of **really important assumptions** that have to be true before you can use Little’s Law and it is in making these assumptions true in our kanban systems that we achieve the true benefit!

The assumptions are (for the period of time that is under observation):

- All measurement units are consistent
- Conservation of Flow which assumes
- Average Arrival Rate == Average Departure Rate
- All work that enters the system flows through to completion and exits

- System is “stable”
- The average age of WIP is neither increasing or decreasing
- The total amount of WIP is roughly the same at the beginning and at the end

**All Measurement Units are Consistent**

This one is relatively easy. If you’re measuring in weeks for Throughput, your Lead time should be in weeks. If your WIP is a User Story, your throughput is in User Story. We can’t have WIP as User story and Throughput as Tasks. We can’t have Throughput as User Story/week and Lead Time as User Story/day.

**Average Arrival Rate (AAR) == Average Departure Rate (ADR)**

This one is a bit trickier, but not too bad. One of the assumptions required, as described by Dr. Little, is Conservation of Flow and this metric is one of the ways that we measure this in Kanban. And the tactic we use to manipulate this situation is our WIP limits. If we only accept new work into our system at the same rate that work leaves our system, we are stable enough for Little’s Law to work.

**All Work That Enters the System Leaves the System**

Work that enters our system and doesn’t exit in a predictable fashion will disrupt the Conservation of Flow. AAR and ADR can’t be equal if this happens frequently in the system. We do have to watch out for work being “created” within the system that could mask abnormal termination of work within the system.

**Average Age of WIP is Constant**

Little’s Law also requires a “Stable System”, which I’m not going to explore deeply in this article. One of the two metrics that we can use from our kanban system though to determine if our system is stable is the average age of WIP in the system. Over the period of time being observed, we want this average to be constant.

**Total WIP at Beginning and End of Time Period are the Same**

The second metric we use to determine system stability is WIP totals at the beginning and end of the time period under observation. If our WIP is trending up or down, we do not have a stable system and predictions that we get from Little’s Law will be suspect.

**So what does this all mean…**

So we have a law that we want to use, but in order to use it, we have to fulfill the required assumptions for the law to work. The required assumptions are going to cause us to create specific and explicit policies that will describe how our teams behave. The effects of these policies are varied, but you will see improvements in prioritization and pulling of work, queuing, swarming, workflow/system design, and WIP limits just to name a few in order to effectively strive to satisfy the assumptions.

**In Conclusion**

The power of Little’s Law to Kanban teams is *not** *its ability to predict WIP, Thoughput or Leadtime. The true power lies in its ability to influence team behavior with its underlying assumptions.

When Little’s Law is properly understood by Kanban teams, it will encourage those teams to strive to satisfy the Law’s assumptions which will result in improved predictability and a kanban system that can be “tweaked” to achieve whatever goal is required at the time.