Ever been in one of those meetings? Your customers and Technical Support team are yelling about a hot bug that needs to be fixed right away.

The developers are saying “That’s not a bug – we didn’t do anything wrong. Look, the code does exactly what it’s supposed to do. Look at the spec!”

The Product Management lead says “No one has ever wanted the code to do THAT before. We never designed for that scenario. That’s not a bug – it’s a new feature. The customer will have to wait for an enhancement release. We can’t put enhancements in a maintenance release.”

“But”, argues Tech Support, “the customer is saying that’s a common business practice. That our software should already be doing it and without a code change they will be getting the wrong information and can’t rely on the product. It’s a big deal.”

What to do? Customers don’t want enhancements in their ‘bug fix’ maintenance releases else it makes it difficult for them to quickly and easily upgrade. On the other hand, is this an enhancement if what is being asked is what customers would expect it would do? It wouldn’t be right to classify it as a bug – bugs mean the developers made a mistake and go against their metrics.

There’s a simple solution – add a third classification to your tracking system.

• Bug for true defects – code that doesn’t match the spec.
• Enh for enhancement requests – new features to be spec’d.
• Gap – Add a new classification for the in-between customer requests. We call them “Gaps”. They are holes in the spec, gaps that the Product Manager forgot or didn’t have enough information about to add. But they are items customers consider a bug.

Having a third classification lets all of the groups agree on how to position customer complaints/calls without having arguments.

• It’s in the spec but not the code – it’s a bug.
• It’s not in the spec and definitely a new feature/request – it’s an enhancement request.
• It’s in-between? Those that everyone used to fight about. Is it a bug so it gets top priority fix? or an enhancement that needs to wait for the next major release? If neither, it’s a gap. It can be in a maintenance release or enhancement release. It wasn’t the fault of the developer. The code is correct. Engineering and Tech Support don’t need to battle it out. It’s simply a gap.

Bug/Enh/Gap – BEG. Having three classifications stopped the arguments and clarified who’s responsible for the fix. Plus clarified what the underlying root cause was, thus aiding our continuous process improvement efforts.

In addition, when only true bugs are classified as bugs, real developer mistakes where the code doesn’t match the spec, then developers take more responsibility for fixing those when other items (holes, missing specs, new features) aren’t incorrectly classified as bugs. Having three classifications encourages accountability and accountability encourages better teamwork.

You won’t have to “beg” any more.