How to Prioritize Bugs π
A few strategies to move fast, reduce conflicts and keep your backlog small.
Bug fixing is not exactly everyone's favorite engineering activity.
It's a tricky process that requires coordination between several stakeholders, and it's not easy to get it right.
Think about it for a moment. Bugs might be reported by Users to Customer Support, reproduced by QAs / Testers, looked into by PMs and eventually addressed by Engineers.
It's a lot of people involved.
Now, every team has a slightly different process for this, but it always involves some version of these steps:
βοΈ Report β bugs are entered in some kind of backlog (...or notified to devs on Slack π₯²)
π₯ Prioritize β bugs are triaged and a priority is assigned. This might be done by QA, PM or Engineers themselves.
π¨ Fix β bugs are addressed and fixed by Engineers.
Out of these three, I have seen the most problems happen in the prioritization stage. Who takes such decisions? How do we avoid conflicts? How much time should we spend on it?
Let's figure this out π
π₯ Stakeholders
When it comes to the importance of fixing this or that, every person involved in the process has their own opinion.
π Customer Support knows about users who need the fix, and what workarounds they have put in place.
π¨ PM knows how bad this is for users and business in general.
π QA knows how badly broken the feature is.
π¨ Engineering knows how bad this is for software.
Every point of view is legitimate and complementary, because no one sees the full picture.
Without a clear process that turns such opinions into actions, you might:
Spend too much time on negotiation β there is only so much time you can spend on deciding what do sooner or later, before it becomes more valuable to use that time for fixing bugs in any order instead.
Have people/roles feel underrepresented β if process is unclear, priorities end up being defined by people with the loudest opinion or the most social capital.
Work on the wrong things β you address issues in the wrong order and reduce the value you could bring.
π― Goals
With that in mind, a good process for bug fixing should achieve two goals:
Get basic priorities right β in a "good enough" fashion, being inclusive with people but without wasting anyone's time.
Ship things fast β so that the order in which things are fixed matters less.
How to achieve these goals? Here are a few strategies π