Great!! You’ve explained perfectly, thanks 
1 Like
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.
3 Likes
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.
5 Likes
hopefully test ninjas count as important 
1 Like
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.
3 Likes
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?”
2 Likes
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.
3 Likes
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.
1 Like
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.
2 Likes
Hi Melissa.
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.
1 Like
We have a Zero-Bugs approach. So not only are bug reports given a Priority and Severity, but they are then given a classification.
… this drives how they are then prioritised.
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.
3 Likes
Frequently I have to advocate for the small bugs or they languish.
One particular case of a word missing a single letter leaps to mind:
Many releases had gone by, and each release we had the same conversation:
- “What’s this?”
- “Missing letter.”
- “Right, let’s bump it to the next sprint.”
Finally I had to point out that 1) if anyone noticed - we look bad leaving it there - and 2) we’ve used more man power talking about it (at least 30 minutes over various releases) and moving the story between sprints than it would take to type the letter and do a pull request (let’s say 5 minutes).
The PM thought about it, laughed and agreed. The bug was prioritised and fixed the same day.
2 Likes
First a bit of context: I’m giving my opinion based from the perspective of an organisation that has a nice micro-services architecture going on with multiple CI/CD pipelines and preferably multiple releases a day. We have speed, and we build small and maintainable changes.
And with that in mind, every bug we find, we fix. And that’s because we have the ability to move fast. We build very small features so we keep the scope of changes to a minimum. This means that an initial bug fix is most of the time a one-liner, which is easy to do and takes very little effort which means the threshold is really low. What also helps with this is that most of our testing is automated, meaning found bugs block the deployment pipelines. And not only for the one DEV that caused the bug, but for the whole team. So there is an incentive to fix bugs asap.
And yes, people can get around this by disabling a specific test, but thankfully we don’t have anyone with that mindset. But if we did… well, let’s say we’ll be having a very unpleasant conversation.
1 Like
This is really interesting, particularly the point that the more ‘agile’ teams feel that spending time assigning bug severity might slow them down.
1 Like