The definition of triage is “the preliminary assessment of patients or casualties in order to determine the urgency of their need for treatment and the nature of treatment required.”
The concept of triage goes back a long way. In the 1800s, Baron Dominique-Jean Larrey, the Surgeon-in-chief of Napoleon’s Imperial Guard laid the groundwork for what would eventually become modern triage introducing the concept of “treat[ing] the wounded according to the observed gravity of their injuries and the urgency for medical care, regardless of their rank or nationality”.
So, how does the concept of triage apply to software development? It’s a way to deal with incoming bugs from customers that helps your development team decide the priority for each bug they need to work on. In a perfect world, your program would be bug-free. Or, if not bug-free, then as soon as a bug was found the team would react and fix it. In the real world, teams will have to work out how and when to deal with those bugs (or not). A regular bug triage meeting can help you do this.
Here, I’ll outline a few tips and gotchas.
Having the Right People in the Meeting
Having a business/product owner in the meeting is vital for a proper triage. They know what is important to the business, what constraints the business has, and the future roadmap. Including someone who understands the application is important. They can supply input on the likelihood of the issue occurring and the context of the bug you’re discussing.
Severity and Priority
This is where the hospital analogy can break down. A broken leg is serious, and even if the broken leg happened because the patient hit their leg with a hammer 100 times, it still should be treated ahead of a person with a minor cut on their finger.
For software bugs, if a crash only happens when a tester hits the same key 100 times, then it’s going to have less priority than a crash that happens when a key is hit once (cue testers commenting on this post about the time a binder fell on their keyboard causing multiple key presses and the system being wiped).
Bug Triage Order
Start with what seem to be the most severe bugs first. The people in the meeting are likely to be pressed for time. That means you don’t want to spend time going through the trivial issues only to find that time has run out just as you reach the critical ones. So yes, implement a pre-triage triage.
Short Summaries
Make sure the summary of the issue is separate from the reproduction steps. You don’t want the people at the meeting to have to read through 30 steps of how to get to the problem starting with “open the app and login” and watch a two-minute screen recording of the exact same steps.
Using the Triage Results
Congrats! You’ve taken this post to heart, set up a triage system, and bugs are being assigned a priority. But you’re not done yet. Are you using the results from the triage? Or, are the doctors ignoring the patients that you’ve so diligently lined up?
Maybe you’re at the point of User Acceptance Testing (UAT) and have found three high-priority severe bugs. Is anyone checking the results of the testing before you push to prod, or do you always push to Prod on a Thursday no matter what the UAT test results were?
And Then…
You’ve got your triage meetings going, they’re running like a well-oiled machine, and critical bugs are being dealt with early on. But, now you have a bunch of really low-priority bugs hanging around and the number slowly increasing? What to do? Read my previous post for some ideas.