Have you been on agile teams that struggle in dealing with defects (or bugs), and ever wondered what are the “best” practices on how to capture these bugs? Below are the first three questions that will guide you in the right direction. WHAT are defect severity and priority? In software development, defects are usually categorized by […]
Have you been on agile teams that struggle in dealing with defects (or bugs), and ever wondered what are the “best” practices on how to capture these bugs? Below are the first three questions that will guide you in the right direction.
A severity is defined as the impact the defect has on the system. In other words, the severity helps answer questions such as: Which process or flow is the defect affecting? Are users blocked by the defect? Is there a workaround?
The severity ranges from Critical or Blocker to Minor or Cosmetic.
A priority indicates the urgency by which the defect should be fixed. The priority helps then answer questions such as: How urgent is the defect? When should the defect gets fixed?
The priority values ranges from High to Low.
At first you’d think that severity should be enough to determine when the defect should be fixed. If it is a cosmetic defect, it certainly is not affecting the user, and thus does not need to be fixed immediately, right?
Well, imagine this scenario: Your team just released a new website for a digital marketing company. The Product Owner comes to you all flushed out, he just noticed that the company logo appears blurred and cut in half. This is a “Cosmetic” severity, but it surely is a “High” priority one that needs to be fixed instantaneously, as it is a highly visible defect that might have a high impact on the image of the company.
So if a priority is enough then to help determine when a defect should be fixed, why do we also need severity? This is a valid reasoning, and many argue that severity is mere bureaucracy. However, many teams find severity helpful in determining common defect trends or development areas that they might want to focus on.
The short answer is the Product Owner. S/He should be the ultimate arbitrator in deciding if and when a defect should be addressed.
For a more elaborate explanation, the following reasoning might do:
Often times, the Product Owner asks for guidance and advice from the Scrum Development Team:
Still, it is ultimately the Product Owner’s call to determine the defect’s fate.
What are your thoughts and experience with defects management? How should defects be managed? Where do we track them? Should we size them?
Whether your budget is based on the fiscal year, the school year, or the calendar...
It’s well over halfway through the year, and if you’re like most people, you set a fitness goal. Have you stuck to it? We know how hard it...