In a previous post I introduced the four assumptions behind Little’s Law and the idea that they are critical to understanding and improving your system’s predictability. We’ve also already discussed the first assumption regarding the equality of average arrival and departure rates. If you haven’t read those previous posts I encourage you to go back to understand the background. As a reminder, the four assumptions are listed below.

Four Assumptions of Little’s Law

  1. The average arrival rate is equal to the average departure rate.
  2. All work entering the system will eventually depart the system.
  3. The average age of work remains constant, neither increasing nor decreasing.
  4. Consistent units are used to measure WIP, Cycle Time, and Throughput.

Today we will focus our discussion on the idea that all work that enters the system must eventually depart the system.

In a Kanban system all work that crosses the Start point of the system must eventually cross the Finish point of that system. Imagine a team discovers that a work item they have started is no longer valuable. They may have discovered that their technology doesn’t allow them to do the thing they wanted or the market has shifted unpredictably and the thing they originally thought would be valuable no longer is. Regardless of the reason for this change, teams in this position may want to throw that work item away. Depending on the tools the team is using this may literally mean throwing a physical card in the trash or it may mean deleting a card from some tracking system. If this work is simply thrown away it becomes impossible to understand the predictability of the system.

Note that this does not imply that we should finish the work simply because we’ve started it. If this work is truly no longer valuable we shouldn’t waste any additional time on it. In order to help us to understand our system more thoroughly and accurately we should not simply throw away this work item but should instead appropriately tag the item as cancelled and mark it as Finished. Both of these steps are necessary in order to enable us to use our metrics effectively. For example, if we are trying to determine how many features we will deploy in the next 6 months we shouldn’t simply perform a forecast looking at total throughput but should instead use a reference class that discards cancelled work and only includes deployed features. Similarly, if we are trying to determine how many features from our backlog will be finished in the next 6 months, we should perform a forecast using a reference class that includes the cancelled work because that is still work that moved through our system and was eventually finished (in this case by deciding we were not going to do it).

The last piece of analysis that should be done based on this data is understanding why this work was started if it would not eventually be used. Are there changes that can be made to your process to reduce how often this happens? Any effort put towards this work that was later cancelled is by definition waste. What could be done to prevent this work from starting in the first place?

Click Here for a discussion on the third assumption of Little’s Law, that the average age of work remains constant.