Nobody likes leftovers. What does that have to do with Software Development?
In a traditional software development program, one of the common discussions is around determining the severity of defects and what kinds, and how many, are acceptable in the shipping product. You’ll hear things like, “Is this a show-stopper?” “Is that an important feature or a nice-to-have?” “Can you live with that defect in production?”
Joe Little, when he taught the Certified ScrumMaster course I took, liked to say that only three things got better with age. I won’t list the three, but defects aren’t on the list.
So, I’ve decided not to have that discussion any more. It doesn’t matter what kind of defect it is, only whether it is a defect. If it’s a defect, it needs to be fixed, period. There is no advantage to putting off the fix of a known problem. It won’t go away by itself. It won’t become less of a problem by itself. And it becomes harder to fix with time.
Is this realistic? In Scrum it’s very realistic. A story needs to have a definition of done. One element of that definition is “no open defects.” Not, “no showstoppers.” Not, “no high priority defects.” Not, “only cosmetic defects.” If you plan to track it, you need to fix it, and fix it now before moving on to the next story.
Once you make this your practice, your velocity calculations will take fixing all open defects into account. You may also find that an environment less tolerant of defects produces fewer defects. You may find that you go to the well of improved development approaches that produce fewer defects in the first place.
On the other hand, if you tolerate a continuous list of “low priority” defects, your overall code quality will be continually bad. Eventually, you may find you have to waste an entire release just on getting your defect backlog under control. You may find that some fairly straightforward refatorings, when taken one at a time, are very expensive refactorings when performed all at once. You will very likely find that your tech debt becomes overwhelming.
Don’t worry about what to do with your expensive defect tracker if you always fix all defects before you finish the story. There will still be that list of defects that your testers didn’t find, but your users did. You can use the software to track those.
You’ll probably find them much easier to address, too.