You know how it goes. Stakeholders start to use the work you’ve produced and then start to highlight that it doesn’t work the way they want. The Project Manager highlights this is what the business signed off on. The developers and testers claim its not broken, it’s that way by design. Is it really a bug? Do you need to start following a formal ITIL Problem Management processes?
How to define a bug, defect or incident
Incident and Problem Management is a big part of ITIL. It’s highly useful in helping people – from stakeholders to team members – understand what a bug really is and what it is not.
- Severity Level 1 defects (Fatal) are defined as:
- Defect completely blocks testing of the Product Backlog Item.
- Defect causes failure of the functionality.
- No workaround.
- Major data corruption.
- Recursive loops.
- Severity Level 2 defects (Major) are defined as:
- Impacts major functionality or data
- Defect causes failure of part of the product’s functionality.
- History records not reported correctly.
- Workaround is not obvious and is difficult to complete.
- Impacts mandatory field validations.
- Impacts on performance.
- Calculations or business rules are incorrect.
- Lookup tables display incorrect data.
- Significant data corruption occurs.
- Message incorrect or absent.
- Impacts on accessibility or usability (e.g. doesn’t meet WCAG 2.0 AA standards)
- Images missing that hinder functionality.
- Severity Level 3 defects (Minor) are defined as:
- Impacts minor functionality or non-critical data.
- Workaround is easy.
- UI layout issues.
- Page titles are missing.
- Spelling and grammatical errors.
- Impacts tab order.
- Impacts cursor focus.
- Images are missing that do not hinder functionality
- Severity Level 4 defects (Cosmetic) are defined as:
- No impacts to functionality or data.
- Does not require a workaround.
- UI colours.
Bugs and the Definition of Done
A typical Definition of Done for an agile software team includes ensuring there are no Severity 1 or 2 defects for the items in the Sprint. Some teams will even go so far as to address any and all Severity 1-2 defects they find, regardless of whether they’re related to the PBIs in the Sprint or not.
Triaging defects when you're in an agile team
Severity 1 defects
When everything is broken, it’s typically all hands on deck to fix the issue.
Severity 2 defects
If defect is part of a Product Backlog item in the current Sprint, the team resolves it this Sprint. If defect is part of a Product Backlog item from a previous Sprint, though, the team typically does the following:
- Creates a Product Backlog Item / User Story
- Product Owner is responsible for timing of resolution in a future Sprint.
If defect can’t be associated with a Product Backlog item:
- Create a Product Backlog Item / User Story
- Product Owner responsible for timing of resolution in a future Sprint.
The Product Owner might, though, negotiate some scope out of the current Sprint in order to address the problem immediately.
Severity 3-4 defects
Minor and cosmetic defects always find their way to the Product Backlog so the Product Owner can determine the best time to address the issue. Sometimes typos and grammar issues are a potential reputational risk, so they often end up finding their way into the very next Sprint.
Help stakeholders understand what a bug actually is
With a clear definition of a defect it’s easy for a Product Owner and their team to explain how they will address quality issues in their work. It’s much easier then when someone claims that something is broken what the definition of “broken” means for your team.
But it still doesn't work the way I want!
If a stakeholder complains that a feature doesn’t work the way they want it’s not unrealistic to spend time with them to find out the behaviour they do want. Using Acceptance Criteria helps to step out what is expected. Spend Backlog Refinement time understanding what the intended behaviour is and write it in a new Product Backlog item for a future Sprint. The stakeholder should engage with the Product Owner to influence the timing of the new work.
When you get to the Sprint Review, walk the stakeholder through the acceptance criteria and demonstrate that the functionality meets the acceptance criteria. If it’s still not the way the stakeholder wants it to work, help the Product Owner to work with the stakeholder to understand and document the new behaviour. Importantly, explain that it’s not a defect – it’s just a change that will go into the Product Backlog.
Conclusions
Stakeholders often get frustrated when things don’t work the way they want. Many don’t understand agile practices, defect definitions, or the way complex products are put together. It’s a Scrum Master’s job to help stakeholders work effectively with an agile team. Being open and transparent and inviting stakeholders to Sprint Review can go along way to improving transparency and trust and reducing the likelihood of angry people complaining about the changes they need to their products.
