A practical bug triage process for small teams

Bug triage has a reputation as a big-company ritual: a weekly meeting, a spreadsheet, a committee debating severity taxonomies. Small teams look at that ceremony, correctly conclude it is too heavy, and then adopt the alternative — no process at all. New bugs pile into an unread channel, the backlog becomes an archaeological site, and prioritization happens by whoever complains loudest.

There is a middle path. Triage for a small team needs about ten minutes a day and one decision rule. This post lays out a process we have seen work repeatedly for teams of two to ten people.

What triage is actually for

Triage exists to answer one question quickly for every incoming report: what happens next? The possible answers are few — fix it now, schedule it, ask for more information, or close it with a reason. Triage is not fixing, not root-cause analysis, and not sprint planning. The moment triage sessions turn into debugging sessions, they stop happening regularly, and irregular triage is barely better than none.

The single-owner rule

The most important structural decision: exactly one person owns triage at a time. Rotate weekly if you like, but at any given moment, one named person is responsible for the inbox reaching zero each day. Shared responsibility for an inbox reliably produces an unread inbox — everyone assumes someone else looked.

The triage owner does not fix the bugs. They route them. This distinction is what keeps the job to ten minutes.

The daily pass: verify, classify, decide

Each day, the triage owner walks every new report through three quick steps.

• Verify: can you reproduce it from the report? If yes, proceed. If no, reply asking for the missing detail — usually steps or environment — and mark it waiting. Reports that arrive with page URL, viewport, and browser attached (as embedded-widget reports do) skip most of this step, which is a quiet argument for collecting context automatically.
• Classify: assign a severity in a three-level scheme. Critical means users are blocked or data is at risk. Major means a real task is impaired but a workaround exists. Minor means cosmetic or edge-case. Resist bigger taxonomies; five-level schemes generate five-way arguments.
• Decide: apply the decision rule. Critical interrupts current work now. Major goes into the next planning cycle with a note. Minor goes to the backlog — or gets closed honestly if you know you will never do it.

That last clause deserves emphasis. Closing a bug as "won't fix, here's why" is a legitimate outcome and far more respectful than letting it decay in a backlog for two years. A backlog you do not intend to work is a lie you tell yourself in ticket form.

Keep the pipeline visible

Process lives or dies by where it happens. If reports arrive in Slack, triage in the thread; if they become Trello cards, make the board's first list the triage inbox and drag cards as decisions are made. What matters is that the queue and the decisions are visible to the whole team in a tool they already open daily. Invisible triage decays into no triage within a month.

A useful weekly complement to the daily pass: a fifteen-minute glance at the backlog every Friday. Not to groom it exhaustively — just to ask whether anything Minor has recurred enough to promote, and whether anything has been "waiting for info" for more than a week (if so, close it politely; the information is not coming).

Watch two numbers, ignore the rest

Small teams do not need triage dashboards, but two numbers are worth glancing at monthly. First, time-to-decision: how long between a report arriving and a next-step decision. Healthy is under a day; a week means the process has quietly stopped. Second, reopen rate: how often "fixed" bugs come back. A rising reopen rate means fixes are shipping without verification against the original report's reproduction steps.

Why this works

The process is small enough to survive busy weeks, which is the entire point. A triage system's value is not its sophistication but its continuity — ten minutes every day beats two hours once a quarter, because bugs are perishable. The report you triage today comes with a reporter who still remembers the details and a codebase that has not drifted. The one you triage next quarter has neither. Keep the loop short, keep one owner on it, and the backlog stays what it should be: a plan, not a landfill.