The bug glide path

Technorati Tags: software development, testing, bugs, scrum

Last week, I attended one of the engineering forum held annually at Microsoft (ala Engineering Excellence & Trust Worthy Computing Forum), which I must say is one of the great perks

for being employed here.  In one of the talk, which was about Agile development, the presenter brought up a very interesting topic -- the bug glide path.

Imagine you are working on a product, and the bug count has already reached its peak.  This means that at least one test cycle has already been conducted and the developers are now completely focus on fixing bugs, and not developing new features (I hope).  After this peak, we all are expecting to see the bug count start a downward trend -- new bugs are filed at a slower rate than the existing bugs being resolved.  Eventually, the bug count will end up at zero, right at the point of release (again, I hope).  Basically, something like this:

(btw, this graph is completely arbitary)

This graph is probably one of the most boring ever because it's so basic and obvious.  Even a middle schooler can understand the intention of it.  :)

However, this is where I found the similarity in bug glide path and Scrum model.  The presenter in fact also mentioned this in her talk which confirm my line of thoughts.  The fundamental reason that Scrum is popular is because of the scale of units that the model deals with.  The whole scrum process deals with small chunk of clearly identified tasks, each with very specific definition of "doneness".  That is, when a task has met its objective as defined by its owner from the scrum backlog, it is considered done.  Very specific, no gray area whatsoever.

This is very similar to the bug glide path above.  Each bug is very specific, small in scale (as compared to the whole product or a feature), each bug also has a very clear and precise definition of done.  If the bug is still active, it's not done.  If it's resolved (and subsequently closed by tester), then it's done.  Once the bug is resolved, you can move on to other bugs.  Once all the bugs in the backlog have been closed, release is imminent.

The same can be said with Scrum.  If we all can divide up the tasks in small granularity which are feasible and yet meaningful, and at the same time define their level of completion consistently.  I believe that Scrum would be a perfect recipe for success.  Each engineers, regardless of their roles, would be able to concretely consume their tasks in the realistic amount of time, and make progress.  This, I believe, is the goal of Scrum to begin with.

However, this is easier said than done.  The difficult part is actually go and start dividing up those tasks into smaller pieces, and then figure out the resources to assign those tasks to.  The most difficult part of all is to actually define what done means for those tasks.