Sunday, 17 May 2009

Can defect tracking systems be more helpful?

I wrote about Visual Representation of Defect Queues a little while ago and the whole idea has been sitting in the back of head churning away.

Most defecting tracking systems are good at showing lists of defects. They also maybe able to show you scoreboards/traffic lights or graphs. Lists are good for a person who has a list of defects in ranked ordered assigned to them to fix or retest. The graphs are good for management as they can see the counts and if they are increasing or decreasing. There is more information than that stored in most defect tracking systems which could come in handy. There is a lot of information store about times things spent in X statuses. The above two examples is either a snapshot in time or a series of snapshots with little information shared between the snapshots. So is there are way to use more of this information stored inside of these defect tracking systems?

Really so far we have got something which is good for the management and the client and something good for the developer defect fixing or tester retesting, nut what about the team lead? Is there a middle ground in between using some of this extra information? How is their team's progress? Can they get a picture of there team in more detail than the managers but maybe a bit less than the developers personal queue?

As mentioned before, in my Visualising Defect Queues post, there is the swim lane type approach. What it can give you is a 2D view of everyone's personal list. Along the X you display the current status of the defect and the Y you can show the severity/priority of the defects. Using index cards stuck to the wall you can some more information as a number on a scoreboard means something, but people are more visual than that, so adding the cards can give you more information. For instance one thing that you can more easily see is bottle necks as it is there in front of you and over the day/week you can just see the cards moving along and you can see bottle necks as large groups of defect start to bunch together. That is extra information which you weren't getting before by just display the information differently. This isn't really using the extra information which is stored in a defect tracking system's database.

If we take the swim lane idea, now we can give each person a colour for the defects assigned to them. Now could get a view for bottle necks as a whole and also the individual people in your team. Is one person sinking? Is it the whole team generally? Could the defects be better distributed amongst the team members? Cool this is now getting more useful and we are using more information in the database to display useful information. What else can we can we display?

Well maybe adjust the transparency of the colour for how long it has been sitting in that status, so now the bottle necks could be more useful again one person may just have the one but they have it for quite a while, so these more opaque cards might need some looking into. There maybe some else has a whole lot of defects sitting with them, but they are the quicker turn around defects so all have the day 1 transparency on them. With just a scoreboard things would look fine as number are moving well and the graph trends look fine but it is masking information about things which could improve your team's performance.

Maybe failed retest could have a border on them to identify them which would mean they might be worth an extra code review as something failing retest more than once never looks to good.

Is this display more information? Yes
Will this lead to information overload? No
Why? Well as if display this visually humans are quite good at picking up patterns from it.
How could this help? Well hopefully team leads can better manage their team and start to see patterns and identify issues with the project sooner than when management ask about a something in particular or the client asks about their pet defect which they raised ages ago isn't fixed.

So what needs doing? Well a defect tracking project needs to take this idea and run with it. Could implement it in flash, so could just drag the little cards around the swim lanes. Then for the people using an old box hooked up to a projector could have it continuously up on the wall, so the defect situation is always there on the wall, just like the story wall in agile. Or maybe MS would like to get in on the act and implement it in MS Surface.

If you were doing one of the Agiles with their swim lanes you could use the same framework. And seeing in Agile things are time boxed, you could have the stories slowly moving across the screen in regards to their complexity and expected time to do. Though maybe this would cause people to rush if they saw things moving faster than they could actually do the work as they found they encountered some type of snag. Which may decrease the quality of the product coming out.

0 comments: