Managing Defects on Agile Projects
This recent Dilbert comic strip reminded me of a situation when a client was raising cosmetic defect as severity 2.
It is often not clear what a defect is and at what level to raise it at (despite agreed severity descriptions) as my example above shows. And some defects are raised without being related to a requirement. Or defects raised because of a feature being “not user friendly”.
Regardless of the reason and how you label the ‘defect’, I treat all defects the same – it is a piece of work required by the client that needs to be prioritized with other work. So the approach is to put all work (defect, enhancement, new feature etc) into the product backlog. As part of the planning process, the Product Owner will prioritize the items on the backlog for the next iteration and/or release. So if a cosmetic defect is more important (has greater business value) than a new feature, then it should be placed higher so it gets completed first.
Keeping all work in the product backlog, makes planning simpler and helps manage the flow of work. It also ensures the client is in control and be the judge of what is important to their business.