There are several assumptions that are part of the conversation about neglected WIP. I have had a lot of training in math and quantitative methods which means I recognize that assumptions are important. Four of the critical assumptions are:

  1. The system you are measuring is under control. A test to judge whether a system is under control is to check whether work is entering and exiting the system at the same rate. Then I check to see that there aren’t wild swings in throughput performance. 
  1. Work items are of similar size. A test for this assumption is whether the team(s) involved break work down so that it will complete within a timebox. In Scrum, that time box is a sprint. There will always be variability.
  1. Work that starts, “normally” completes. I use the term normally in this assumption because, in knowledge work, we all know that stakeholders change their minds. When that happens, cancel the work and get it out of the system. Note that if this is more than a rare condition, the system is not under control.
  1. WIP doesn’t vary wildly between the start and end of the study period. In Kanban this is easy; Scrum’s fixed timeboxes where the board should start empty and end empty make this assumption a bit more problematic. In Scrum, I shade the assumption by measuring mid-sprint to mid-sprint – it is a hack.

These assumptions make Little’s Law and neglected WIP mathematically sound. A bit of inappropriate sharing – I sometimes cheat on assumptions when I use the concept of neglected WIP as a conversation starter in a retrospective. Using the equation to give the team even a rough idea of how much WIP churning starts a conversation faster than asking questions or making observations. Occasionally, teams need “something” to help them shift their perspective when doing a retrospective or an operations review. Neglected WIP is useful even if you have to cheat on an assumption or two to help highlight or triangulate a problem. Be transparent if you cheat on an assumption and only do it as a conversation starter. Never play fast and loose with reporting.

An example (nearly real life):

A team’s kanban or Scrum board has 100 items in various states of completion. More than a handful of those items are older than dirt (pretty old). Based on the assumptions above, it would be fairly safe to say that the system is not under control. It might even be possible to make the argument that the assumption about things entering and completing (#3 above) might also be a problem. The violations of the assumptions would suggest not using the calculation of neglected WIP.  This team knew it had a WIP problem but they always explained it away. In this case, using neglected WIP is useful as a tool in a retrospective for at least two reasons.

  • 1. The use of neglected WIP provides a second point of reference to what should have been painfully obvious. They had too much WIP. The combination of rationalization and a serious addiction to heroics made the topic impossible to raise. The amount of churn, switching between work items also known as which made the amount of context switching, was awe-inspiring. By calculating neglected WIP the team had to confront a different frame of reference. The “math” made it harder to rationalize. Absolute mathematical purity was less important than breaking through rationalization.
  • 2. The loose calculation of neglected WIP gave the team a goal to start working toward. When we introduced the concept in a retrospective, the team started working on ideas to throttle their uncontrolled work entry process. The ability to see both WIP and neglected WIP recede provided the team with the motivation they used to drive process improvement. Having a goal helps to generate impetus.  

The example is an illustration of why abandoning one of the key mathematical assumptions underlying neglected WIP (and Little’s Law) is useful if done carefully. I am not suggesting abandoning mathematical assumptions with absolute impunity nor am I suggesting hiding what you are doing (that would be lying). I am suggesting that sometimes it can be useful and sometimes being useful is what is important.