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 severity and priority.
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.
WHY do we need severity and priority?
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.
WHO should be involved in defect reporting?
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:
- A defect has a priority that indicates the urgency by which it needs to be fixed based on the business. (Hint: refer to the “Cosmetic” defect story above)
- A defect is when a Product Backlog Item (PBI) does not meet the acceptance criteria
- The PBIs and their acceptance criteria are owned, managed, and prioritized by the Product Owner
- Thus, logically, the Product Owner is the ultimate arbitrator of defects.
Often times, the Product Owner asks for guidance and advice from the Scrum Development Team:
- The Product Owner could seek the business analysts (BAs) or the testers input in making priority decisions. The BAs and testers are usually involved in design, requirement gathering, and acceptance criteria writing. Thus, they possess the business knowledge to make such a priority judgment.
- The Product Owner could also consult with the developers to get their technical perspective on the impact of the defect and the cost to either fixing it or not fixing it.
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?