The Most Valuable Field Missing From Your Bug Form

  • Article

The order of fixing bugs is like the order used to pack a truck when you move.  If you have ever moved yourself you know that packing the biggest and most fragile items first in the truck is important.  You can fit the smaller and sturdier things just about anywhere in the truck at the end.  If you run out of room the smaller things can go with you in the car.   You want to get as many as the big and fragile bugs\boxes into the truck as possible so you load them first.   You don't want to be left with the refrigerator not fitting in the truck at the end.

moving-truck

The same is true with bugs - you want to fix the highest priority bugs that are the biggest (most time) and fragile (complex) first.  Think of the moving truck as the amount of time and resources you have to fix bugs.   To optimize this space bugs should be fixed in priority order with the most difficult and time consuming ones first.  You can fix the smaller and easier ones late in the game without jeopardizing the schedule.  If you wait too long to fix difficult bugs there is increase risk to the schedule because there is not enough time to test the fix OR the a fix won't be provided at all because of the risk.  In either case, the quality of the product suffers.

Often in practice, the exact opposite behavior happens.  Teams want to show measurable progress so even though they may fix bugs in priority order the easy ones tend to be done first. 

Quick - go look at your bug form.  Go ahead, I'll wait....  Is there a field that quantifies the level of difficulty of the fix?  Most likely the answer is, "no".   Some imply this from the priority or severity of the bug.  However, this is often not the case.  For example, a null ref crash is priority\severity 1, but is often trivial to fix.

 

Specifying Difficulty

Specifying the difficulty of fixing a bug is like any other software estimation practice - it is not an exact science.   Sometimes you are not really going to know unless you dig into the bug more.  Avoid spending too much time trying to determine a precise level of difficulty, the goal is to get the right order of magnitude. 

Quantifying the difficulty of addressing a bug should factor in 3 elements:

  1. Complexity\risk - how many components and moving parts are involved?
  2. Duration - gut estimate of how many hours/days it will take to fix and test
  3. Expertise - does this bug require rare specialized knowledge?  If so, get this fixed as soon as that expert is available

You can keep it simple and use T-shirt sizes to measure difficulty - small, medium, large or use a numeric value.  Some may find it valuable to place duration is a separate field for scheduling and load balancing purposes.

Regardless of how you specify the level of difficulty, fixing bugs in priority and highest level of difficulty order will decrease risk and improve the quality of your software.  Don't be left with the refrigerator not fitting in the truck.