RSS

Discuss Each Bug Report Only Once

12 Jun

Run your team in an action oriented way.  Sometimes, the same bug gets discussed over and over, and this represents a waste, particularly when they are discussed in a group.  Be mindful of this, and while it is not entirely possible in all cases, try to discuss a bug once and only once.

The purpose of a bug tracking system is to act as a buffer between the users/testing and the development team.  It is normal that many bug reports will be entered at one time, sit in the bug tracking system for a while, before finally be handled by a developer.  If proper prioritization is in place, then some of those bugs deemed higher priority will be handled quickly, and lower priority bugs will tend to sit around for a long time.

Here are some tips to follow to keep this overhead at a minimum:

  • Use  a “quality council” to assure that the bugs are prioritized correctly.  In this case “correct” means that there is a common agreement across the council about the priority of a particular bug.  It is necessary in many cases to discuss the details of a bug, and to explain the significance of it.
  • Pre-estimate fix duration.  Before discussing a report at the quality council, a developer should have reviewed the bug report, and estimated a simple “Small/Medium/Large/ExtraLarge” estimate for work needed to fix the problem
  • Do everything you can to solve the problem in that first meeting – contacting a specific developer might interrupt the meeting, but if you can close the loop with everyone right there, and be done with it once and for all, you will win.
  • Fix “small” problems without delay. Don’t even discuss them.  A small problem can be fixed in a few moments of work, so just do it.  Any discussion is a waste of this level problem.
  • Discuss bug once, mark priority, and don’t discuss again.  Once a bug is brought up for discussion, try to make a decision about it, and move it on to the next stage.  This is not always possible, and sometimes you have revisit bugs, but those should be a small minority.
  • Eliminate backlog one way or the other.  Don’t leave a large number of bugs hanging around for a long time.  Either fix the problem.  Or decide that you do not have the resources and mark it as “will not fix”.  Do not let the pile of unfixed bugs pile up to a huge level.
  • Empower developers to move.  Don’t insist that all changes be reviewed by the council, but instead allow developer to proactively fix things that need fixing.
  • Encourage direct developer interaction for small bugs.  The most ridiculous waste of time is discussing spelling errors in the help files.  In fact, it is a pretty big overhead just to fill out the formal bug report for these.  Consider this: have a developer on call.  The user/test calls them up, points out the spelling errors, and the developer changes and commits them immediately.  This might interrupt the developer for a few minutes, but the savings for everyone else will be a net benefit.

The goal of kan-ban style development is to minimize the amount of stuff being currentyl worked on.  The same principle applies to bug tracking:  Handle the small cases as quickly as possible, and the large cases discuss only once if possible.

Jim Barksdale, the CEO of Netscape used to say:  “If you see a snake, kill it.”   That is, don’t spend a long time discussing problems and planning to solve problems.  Instead, find and fix problems individually without delay if possible, and get on to the next thing.

Advertisements
 
Leave a comment

Posted by on June 12, 2013 in practice

 

Tags: , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: