Not to be confused with Crouching Tiger Hidden Dragon; or even a movie with a fancy/odd name…..

Crouching Tiger – Flying Dragon is the phrase I came up with while trying to give a name to a defect backlog bashing initiative.

Why Crouching Tiger – Flying Dragon?

The # of defects in the backlog is large; about 2200 cases large. Each case requires analysis, appropriate documentation and appropriate team assignment. For example a case may be a hardware issue, a question/concern, a software defect, incorrect client configuration, etc. This effort takes hours and in most cases multiple interactions with the client reporting the defect to obtain all the appropriate information. Putting all interruptions and need for multiple contacts aside, It takes at least 8 hours to document all the needed data. With the # of resources available, were looking at a year to get it all documented, assuming of course that no interruptions, PTO or other cases come up.

So how do you tackle this?

Ideally, if every case in the backlog had appropriate documentation and was assigned to the appropriate group, each group could then analyze all the cases and look for trends and similarities so that multiple cases could be grouped together.In addition to that, what has been learnt through metrics is that 10% of analyzed cases end up with the development team as software defects. From this 10%, only 52% turn out to be software defects…. So we are actually talking about 5% of the 2200 cases are actual defects….. If only there was a definitive way to magically find the 110 needles in this haystack….

In my organization there are support analysts and development analysts. Support analysts are on the front facing customers, development is in the back, non-customer facing.

The challenge is that we do not know which 5% are defects and we also don’t have time to go through all cases… So along comes Crouching Tiger – Flying Dragon.

Crouching Tiger: The support analysis team will spend 1-3 minutes per case that they are assigned to.. Were looking at a few hours per analyst…. While they spend these few minutes, the goal is to read the documented/reported issue and use their knowledge and experience to decide which group the case probably needs to end up. If they run into a case they believe is not a defect or is already resolved, it will be closed. We want our tigers head down, crouching, going through everything in their queues.

So where’s the flying dragon?

Flying Dragon: Once the tigers are done; we expect that we won’t have 5% of 2200; we may have 50%….. this is still better than having majority of the cases in an unknown state. Since capacity for analyst review doesn’t exist; effort must be made to have any resource help in anyway possible to eliminate the backlog. Let’s say we end up with 300 cases in development. Once we have these cases, we can run through them in multiple passes/phrases to get them appropriately refined. For example, pass 1 will focus on checking to see if development analysis results in dose closure (already resolved) and what component is the reported defect related to. Pass 2 focuses on refining the component to a more specific area. Pass 3 focuses on grouping similar issues or issues within a code area. These multiple passes represent the Flying Dragon and once we have the groupings we can convert them to projects that will be prioritized. The goal will be to resolve a defect area at a high level rather than a per case view; giving us a birds (dragons) eye view of what was broken.

Another motivator for picking this phrase was based on the fact that everyone in my org is functioning over capacity, multitasking and always on the go; having support stop and focus on going back to their queue backlog does make them crouching tigers for a bit. As soon as they are done the dragons will start flying through the multiple passes….. Getting us closer to success.