I've been around and around with people on the definition of "bug" when it comes to software development. In the realm of Scrum, I've settled on my own definition. In the Bradley Bug Chart , I have this definition for a Bug:
  • PO would agree that there is unacceptable system behavior, AND the Dev Team believes that the behavior is inconsistent with requirements that were previously understood by the Dev Team. Be honest! Also, if it takes longer than 10 minutes to decide if the issue meets this definition, flip a coin to decide whether it is a bug or not, because it's not worth spending any more time on it right now. You can always come back and re-classify later (if you feel there is value in doing so).

Note that if you're doing requirements the way I think you should be doing them(User Stories or some other form of Acceptance Test Driven Development), you can replace the word "requirements" with "acceptance tests."

"PO would agree that there is unacceptable behavior..."

There are some cases where the PO doesn't agree that the weird behavior that has been discovered is really unacceptable. Whenever you get so called "bug reports" submitted by users and other stakeholders in an issue tracking system, there is not necessarily unacceptable behavior as judged by the PO. Whether or not it is unacceptable behavior is business decision that only the PO can make. Even if there is behavior inconsistent with previously understood requirements, the PO may still not consider the behavior unacceptable. Our first step here is to do a reality check and make sure the PO thinks the behavior is unacceptable.

"...the Dev Team believes that the behavior is inconsistent with requirements that were previously understood by the Dev Team..."

The PO has the ultimate responsibility for communicating requirements, especially since they are the ones who decide on "The What" in terms of functionality required. Ideally, this is a highly collaborative process between the PO and Dev Team, but again, the ultimate responsibility falls on the PO for making sure requirements are communicated clearly, and for making sure the PBI's are implemented correctly. In my view, when the Dev Team thinks a PBI is complete, the PO should give Immediate Story/PBI Signoff (or the equivalent). The form of this "signoff" can be very simple, verbal, etc, but I feel it's vital for the PO to give immediate feedback and confirm that the PBI has met its acceptance tests. Circling back to how this affects the definition of bug -- if a requirement was not well understood by the Dev Team, it's not really a software bug. I call it a "Requirements Bug", and that means it's a new PBI. Don't take this to the extreme, though. Minor clarifications and changes are fine, even late in development. For details on that, see Handling Scope Changes Mid-Sprint .

"Be honest!"

All parties need to be honest and frank in this discussion. Any attempt to be dishonest or "game the system" is a problem that goes way far beyond the scope of this article or strategy. I find that a very high percentage of software people are incredibly honest about such things, but for that small percentage that like to play "perception games," these two words are for you!

"...if it takes longer than 10 minutes..."

This section is pretty self explanatory. I don't want my advice to be used an excuse to have drawn out discussion about whether something is a bug or not. If you're doing this, you have bigger problems that should be retrospected on.

Examples of things that are not a software bug:

  • Requirements Bug - As discussed above, a requirement that was never communicated to the Dev Team, or that was never communicated in a way that the Dev Team understood.
  • Not a bug - Just because it was entered in a "bug tracking" system, doesn't mean it's a bug. We often investigate things and find out later, "That's not a bug -- it's actually expected behavior of the system."
  • New Feature/PBI - Sometimes users and stakeholders mistake a bug for what is really a new feature. These people define bug different than I do. They define bug as "Anything I don't like in the system."
  • Ignored Bug - The behavior is inconsistent with requirements previously understood by the Dev Team, but now the PO thinks that the behavior is not worth worrying about in the foreseeable future(next 12 months), or that the behavior is now considered to be acceptable. This is extremely rare, but it happens, and it is represented as one possible reason for Step 5B on the chart. When the PO makes this decision, they are essentially saying that this is not really a bug at the current time.