A Repeatable Bug Triage Workflow
A simple, repeatable workflow for triaging incoming bugs so nothing important gets lost and nothing trivial blocks a release.
Bug triage goes wrong in two directions: important issues sit unnoticed in the backlog, or trivial ones consume attention a release cannot spare. A repeatable workflow keeps both from happening by making triage a routine, not a debate.
Triage answers three questions
Every incoming bug needs three decisions, in order. Skipping any of them is where triage breaks down.
- Is it real and reproducible? — a bug you cannot reproduce is a research task, not a fix task.
- How severe is it? — impact on the user and the business, independent of how easy it is to fix.
- When does it get fixed? — now, this release, or the backlog.
A severity scale everyone shares
Severity arguments happen because nobody agreed on the words. Pin them down once:
- S1 — Blocker: core function broken, no workaround, blocks release.
- S2 — Major: important function broken, workaround exists.
- S3 — Minor: limited impact, not release-blocking.
- S4 — Trivial: cosmetic, cleanup when convenient.
Severity is about impact; priority is about when. They are related but not the same — a low-severity bug on the demo screen before a big demo can still be high priority.
The intake checklist
Before a bug enters triage, it needs enough information to decide. A quick gate saves hours:
- Clear title describing the actual problem
- Steps to reproduce
- Expected vs actual result
- Environment (build, device, OS)
- Severity proposed by the reporter
Bugs missing these get bounced back with a request, not triaged on guesswork.
Make it a routine, not an event
The teams that triage well do it in small, frequent passes — a short daily or every-other-day review — rather than a giant painful meeting once a sprint. Frequent triage keeps the queue short, and a short queue is one people actually read.
Close the loop
A triaged bug should always leave with an owner and a decision, even if the decision is “won’t fix”. An explicit “won’t fix” with a reason is a finished decision; a bug sitting untouched for months is an unfinished one that quietly erodes trust in the tracker.