Bug Triage

Definition

Bug Triage is the recurring meeting — usually daily or every other day — where newly reported defects are reviewed by a small group with the authority to classify, prioritise and assign them. The name is borrowed from emergency medicine, where triage is the process of deciding, under pressure and with incomplete information, which patient gets treated first. In software the pressure is lower but the principle is the same: not every bug can be fixed immediately, so a defensible process decides which are.

Why It Matters

Every product team eventually accumulates more open bug tickets than it can fix. Without triage the backlog becomes a landfill — nobody knows which items still matter, engineers cherry-pick the interesting ones, real regressions hide underneath duplicates, and support staff give customers vague answers because they cannot see a plan. A working triage process converts the bug list from a passive archive into a live prioritised queue that the team can execute against, and it gives support, product and engineering a shared language about severity and urgency.

Anatomy of a Good Triage Meeting

• Held at a fixed cadence — daily for a live product, every other day for a slower one — and time-boxed to 20 or 30 minutes.
• Attended by a small triage group: engineering lead, product owner, support representative, occasionally a QA lead.
• Works through a single filtered view — "new bugs since last triage."
• Each ticket receives severity, priority, area, owner (or "needs investigation"), and either a target release or a "not planned" decision.
• Actions are captured in the tracker, not in a meeting note.

Severity vs Priority

These get confused constantly. Severity is the technical impact — data loss, crash, wrong result, cosmetic. Priority is the business decision — fix now, next sprint, backlog, wontfix. A cosmetic bug on the checkout button can be low severity but high priority if it is costing conversions. A crash in a rarely-used admin feature can be high severity but low priority. Both dimensions belong on every ticket and both drive the schedule.

Real-World Example

A B2B SaaS product had 1,847 open tickets in its bug tracker and a 42-day average time from report to resolution. New reports were being missed for weeks. The team introduced a daily 25-minute triage at 09:30, with a fixed filter for tickets created in the last 24 hours and a rule that no ticket left the meeting without an owner or a "wontfix" decision with reasoning. In eight weeks the average time to first action dropped from 42 days to 1.5 days. The open count did not initially move — because the team also spent one triage per week culling the historic backlog, closing duplicates, stale tickets and tickets against features that had been removed. After a quarter the open count was 340, all with owners and target releases. The lesson was not that the team started fixing more bugs. It was that they started making explicit decisions about the bugs they were not going to fix, and both customers and engineers now knew where they stood.

Practical Lessons Learned

• Every ticket leaves the meeting with a decision. "Needs investigation" is a decision — with an owner and a due date, not a permanent parking spot.
• Duplicates must be closed, not merged and forgotten. A duplicate that stays open pollutes every metric.
• "Wontfix" is honest and respectful. Customers prefer a clear "no" over a silent "maybe" that lasts three years.
• The triage group needs authority. If every priority decision has to be escalated, the meeting is a queue, not a triage.
• Separate the incident channel from the bug channel. Production incidents follow the incident management process, not the triage queue.

Expert Tips

• Publish the severity and priority definitions in the same place as the ticket template. Support engineers who write tickets against clear definitions produce triage-ready reports.
• Set a weekly cull slot — 30 minutes to close stale, duplicate or obsolete tickets. Without it the backlog grows even when triage is working.
• Track "time to first triage decision" as a KPI, not just "time to fix." The first metric measures the process; the second measures capacity.
• Rotate the engineering triage seat quarterly. It spreads product context and prevents one person becoming the only holder of the historic decisions.
• Automate the easy classification. Templates, forms and category-tagging bots do most of the initial sorting; humans handle the judgement calls.

Common Mistakes

• Treating triage as a status meeting instead of a decision meeting.
• Confusing severity and priority; using only one and losing the other dimension.
• Letting tickets accumulate as "needs investigation" with no owner.
• Never culling — the backlog becomes uninformative and the team stops looking at it.
• Doing triage without a support representative — customer impact context is missing.
• Routing production incidents through triage instead of the incident channel.

Key Takeaways

• Triage is a decision meeting, not a status meeting.
• Every ticket leaves with severity, priority, owner and a target — or a documented wontfix.
• "Time to first decision" matters as much as "time to fix."
• Cull weekly; a bug tracker without a cull is a graveyard.
• Incidents are a different flow — do not conflate them with the bug backlog.

Related Concepts

Interlocks with Backlog Refinement, Incident Management, Definition of Done and Error Budget. Triage templates and severity/priority matrices at PMMilestone.org.