Surprisingly, there isn’t much agreement on what a defect is or how they should be addressed. This page explains our position on defects and how we feel they should be dealt with.
Note: We’ve come across a few teams recently that use bug and defect to mean different things. We do not make any distinction between them - in this article, a bug is the same as a defect.
Definition
It’s a defect if:
- The team knew what it was supposed to do
- And it doesn’t do that thing
- And the team said they were done
All three points are important.
The team knew what it was supposed to do
We often hear the complaint “we built what they asked for but then they said it was broken because it didn’t do this other thing that nobody had ever discussed.” Is this a defect? Well, it’s a defective form of communication that you have with your business users but it’s not a software defect. If someone decides that they want something changed after it’s written then that’s just a new request to the team. If the team knew what was needed and the software doesn’t do that thing properly then that’s a defect and needs to be fixed immediately.
If this disagreement is happening regularly then perhaps the team needs to revisit their definition of “ready” so that the right conversations are happening before the team starts to work on the stories.
And it doesn’t do that thing
This should be clear. Does it work as expected or not?
If you aren’t sure whether it does what is expected then you probably need to be more precise in your description of the story. Do you have good acceptance criteria? Is it clear who you are building it for or why it’s important?
Writing effective user stories is difficult for most teams. It’s worth spending the time to get better at it.
And the team said they were done
The story clearly isn’t broken if the team is still working on it. Once the team says they’re done, however, we expect it to be working. The team should have a clear definition of done so we know when we’ve passed this point.
Stories don’t get to stay in development forever.
When using an iteration based approach like Scrum, you’re supposed to be done no later than the end of the iteration.
Fix defects as soon as they’re found
I’ve seen far too many companies that have hundreds of known defects at any given time and somehow think this is ok. A defect is a place where we know what the code is supposed to do and it doesn’t do that thing. That’s not ok. That means that we didn’t do the job right and we didn’t go back to fix it.
Presumably any piece of code in the repository was requested to solve a problem the business was having. If it doesn’t work then we need to fix it.
We all make mistakes. The fact that a mistake was made, isn’t the big problem. The big problem is when we don’t fix that mistake. An even bigger problem is when the culture allows for these mistakes to go unfixed forever. A culture of technical excellence will not allow defects to remain unfixed, fixing them as fast as they’re found.
If your team is having arguments about what a defect is then your communication/feedback is broken and you need to fix that. Start having conversations and involving the business more in the development.
When a defect is discovered, it should be immediately fixed. Not tracked. Not discussed. Not prioritized. Just fixed.
Looking at it a different way, a defect is unfinished work. We built something but it still doesn’t do what’s its supposed to do so we’re not finished yet. We shouldn’t be starting new work if we haven’t finished the pieces we were working on earlier.
If your team has a rule that no new story will be started if there are any outstanding defects then your defect count will quickly drop to zero and will rarely be more than a small handful at any time.
When the business doesn’t care about the defects…
What if your product owner doesn’t want the defects fixed? We’ve been involved in many conversations where the product owner wants new features implemented instead of fixing older features that are broken.
The answer to this is surprisingly simple. If the product owner doesn’t care about fixing broken code then this may be code that wasn’t important in the first place. If it wasn’t then perhaps we should remove it. The very fact that it isn’t important enough to fix is an indicator that we may have bigger problems and that we should look at that.
Is the defect in something that used to be important but isn’t anymore? The same applies - if it’s no longer important then let’s see if we can remove it.
There are definite lessons to be learned if the business doesn’t care about defects. Take the time to identify the real issues and fix those.
Spelling mistakes and other “trivial” defects
People often bring up spelling mistakes, minor UI tweaks and other “trivial” defects as examples of things that aren’t important enough to fix. In our opinion, this is sloppy work.
Teams that take pride in their work, do consistently better work than teams that don’t. Is your team ok with delivering sloppy work or do they want to be proud of what they build?
If they want to deliver high quality work then little things like spelling mistakes can’t be allowed. They should be fixed as soon as they’re found.
Do we put estimates on defects?
Our advice is to not estimate defects for two main reasons.
- Defects are unfinished work. Had we implemented the original story correctly, there would be no defects. Giving the team “credit” for finishing up something after they said they were done just encourages the wrong behaviours.
- Estimates on defects are typically useless anyway. By the time we know enough about the defect to be able to put an estimate on it, we’re usually almost finished with it. So any estimates we put are really just noise.
Are bugs a form of technical debt?
We’re often asked if defects are a form of technical debt and the answer is no. Defects are places where the code is actually broken. We know what it’s supposed to do and it doesn’t do that thing.
Technical debt, on the other hand, is code that is working but is implemented poorly. The key characteristic of technical debt is that it slows down ongoing development work. Technical debt is often a source of defects but is not a defect in itself.