The best bug triage meeting I've ever sat in was over in four minutes.
They had not mastered triage. There was barely anything to triage.
I have 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 of it moved defects through the queue more efficiently.
A heaving triage queue is a manufacturing problem, and nobody wants that on the roadmap. Deming argued in Out of the Crisis (1982): you cannot inspect quality into a product. A faster triage process inspects 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 is coming from somewhere else.
The best team I have worked with had a near-empty triage queue. Here is 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 sorts itself out.
into your process?
A QA Review finds the gaps in 1–2 weeks. From £1,200.