Great!! You’ve explained perfectly, thanks
I would include that in a category like Impact, meaning my matrix would have the values Impact and Frequency/Urgency.
Impact - what damage will the bug do on a productive system? What are the consequences? That could include how detectable a bug is - software could run and nobody notices that wrong data is written.
Frequency/Urgency - How often does it happen? Once in a lifetime → probably not that urgent. Urgency could also include the value of customer, being higher if the customer is someone that works on important systems with the software or is simply paying a lot of license fees.
I know that’s really close to (if not downright copied from) ITSQB standards, but in this case they make a lot of sense to me.
If the person shouting at you is very important then the bug is high priority.
If the person shouting at you is not important then the bug is low priority.
hopefully test ninjas count as important
We’ve tried to tag these kind of issues (things like “easy-fix”, “busy-work”, etc) so that they can be picked up opportunistically when a dev has finished their sprint work but doesn’t feel like they can pull in the next story at the top of the backlog.
We’ve had mixed results with this, and usually it’s a matter of someone just championing these small things and getting them into sprints.
Of course, the other answer to that is “How stupid is this going to look on social media if someone else spots this and retweets it?”
Corollary: If the customer is shouting at the CEO, the bug is high priority.
Slightly less obvious corollary: If the CEO insisted on releasing with the bug(s), direct the shouting to the CEO.
Some time back (with a different CEO) my team was required to release a feature we were not happy with. It had been promised by the CEO on a specific date, and we weren’t given any choice in the matter despite the rather extreme challenges involved.
We’d told him that to deliver the feature in a stable, secure environment would take a year more than we had (very small team - everyone multi-tasked). It took a year of emergency patches to stabilize what we delivered.
We directed all feedback to the CEO… Strangely enough, he started listening to us when we told him roughly how long it would take to make changes to the software.
For us creating tickets for mistakes, no matter how small, really helped. We needed a company wide policy change that our Devs accepted us raising them. But this resulted in them being fixed more as well as people are made aware. They are mostly easy fixes, like @ernie wrote something nice for in between.
It also helps to have a UX/UI person to back you up. They see those kinds of issues as more important than others.
We’ve expanded from a simple Impact / Frequency matrix into something that caters for more.
We use bug priorities of P1-5:
- P1 - Emergency (fix now)
- P2 - Critical (fix in 2 days)
- P3 - General bug (fix in next 1/2 sprints)
- P4 - Low priority (fix in ~1-3 months)
- P5 - Lowest priority (fix in ~3-6 months)
To determine the P value we put each bug through a grading criteria where we score (on a 1-5 scale):
- Severity - Describes how the defect impacts the functionality
- Impact - Describes how many customers are affected
- Priority - Describes how bad the overall user experience becomes
We also consider workarounds, key client impacts, etc into the score. This all comes together to give us the P value which we then action accordingly and bring into sprints based on the time criteria.
Do your p4 /p5 bugs get fixed within the timeframe? In some experience I’ve had, they get forgotten about and the focus is on P1 to p3.
As I see it is that you have different impact of a bug and that is what determine the severity.
And as many of you have point out that Critical/High or Major is something that is easy to get attention to.
But the Bugs that have less impact and will most likely not be fixed at all.
I think that we should change our mind about these Bugs.
I think it would be better to change these low prio Bugs to Improvements instead.
Then it will end up in the backlog and it will be prioritized with all other development tasks.
So we go for a Zero-Bug approach.
We have only Bugs for something that the team will do something about everything else is improvements.
Tbh you’re spot on, P4s and P5s tend to breach SLAs due to the amount of normal sprint work and P1-3 bugs that come in.
It really requires someone to own these lower priority bugs and ensure that they are pulled into sprints and no forgotten about. If no one takes on this role, they will never get done and it would be better to tell the client that you actually aren’t going to fix them and set that expectation.
We have a Zero-Bugs approach. So not only are bug reports given a Priority and Severity, but they are then given a classification.
All bugs (classified as Critical or Bug) take priority over feature work. If ‘you’ can live with it, then it is an improvement and should be allocated priority within your feature backlog. It all comes down to an agreement between Product Owner, Delivery and the Business.