thefrugalprogrammer

There's an aspect of ticket tracking I'm sure everyone has encountered at one time or another: The line in the sand is Major; we will fix no issues marked as Minor. There is political capital in fixing only major issues, especially with limited resources. It allows development teams to scuttle features by relegation. And it shows upper management that all resources are completely spent -- we can only fix Major issues until we hire more staff.

In reality, development teams need to look at the classification problem with internally consistent values. Fixing minor issues is important because some of the minor cosmetic issues are what your customers see first. Tracking minor issues allows you to show improvement from release to release and accurately track team improvement. Pragmatically, however, chase the deer not the squirrel; the bugs and improvements that receive highest priority should be the things that improve the overall quality and desirability of the product the most, not just one off's for existing customers. This can become the inverse of the Major sand line -- the never-ending squirrel chase.

Most importantly: if it takes you longer to argue about the merit of fixing a problem instead of just fixing the problem, then perhaps you should just fix the problem and Ask For Forgiveness Later™.

Maybe there's a certain inherent optimization in the Major / Minor problem: You are too lean if you can fix only Majors. You are too fat if you are commissioning side projects that have nothing to do with your core business.