The best bug triage meeting I've ever sat in was over in four minutes.
Not because they'd mastered triage. Because there was barely anything to triage.
Triage processes that have quietly caught fire, I've watched teams pour enormous effort into triaging faster — better labels, tighter SLAs, a Jira board with more columns than a spreadsheet of Roman emperors. All to move defects through the queue more efficiently.
Here's the bit nobody wants on the roadmap: a heaving triage queue isn't a triage problem. It's a manufacturing problem. Deming said it back in 1982 — you cannot inspect quality into a product. A faster triage process just inspects the defects more efficiently. It does nothing to stop you making them.
Optimising triage while the real issue sits upstream is like buying a bigger mop because the bath keeps overflowing. (Impressive mop. Still a wet floor.) The water's coming from somewhere, and it isn't the queue.
The best-quality team I've worked with had a near-empty triage queue. Here's why:
- Defects got caught in design and pairing, not three weeks later by an end user in Slough.
- "Done" meant tested, not "works on my machine, maybe."
- When a bug did slip through, they asked why the process let it in — not just how fast they could close it.
- Nobody got a pat on the back for triage heroics, because heroics meant something upstream had already failed.
A fast triage queue is a tidy symptom. An empty one is a healthy system. Aim for the second and the first quietly sorts itself out.
When did your team last fix the upstream cause of a bug, instead of just triaging it faster?
into your process?
A QA Health Check audit finds the gaps in 1–2 weeks. From £1,200.