Igor
A bug triage meeting decides, for each new bug, what happens next: fix it now, fix it later, ask for more information, close it, or merge it with another. It can take 15 minutes if you prepare, limit the time per bug to about a minute and give every bug exactly one of five outcomes. This post gives you the attendees, a timed agenda, the rules and a notes template.
What triage is for
Triage is not debugging. Nobody opens the code. The meeting exists so that every new bug gets a decision and an owner, so that the backlog does not fill with reports nobody has looked at. If you are tempted to investigate a cause in the room, the outcome for that bug is "needs more information", and the investigation happens afterwards.
Who needs to be there
- A chair. Someone who keeps time and says "next". Usually a QA lead or project manager.
- Someone who decides priority. The product owner or the person who speaks for the business. Severity is a technical fact; priority is their call. See bug severity vs priority.
- A developer who can say roughly how big a fix is.
- QA or the reporter's representative, if the bug needs explaining.
Four people is enough. Every extra attendee adds time without adding decisions.
Before the meeting
Fifteen minutes only works if the chair prepared for ten. Before the meeting, filter the tracker to bugs created since the last triage that have no owner. Sort them with the most severe first. Remove anything that is clearly a question or a feature request and answer it by message. Then check each bug for the minimum a decision needs: steps, what happened, what was expected and the page. A bug that lacks these goes straight to "needs more information" with a comment, before the meeting. This is where the quality of the original report pays off; a report that arrives with the console errors, the requests and the steps already attached rarely needs that comment.
The 15-minute agenda
| Minutes | Item |
|---|---|
| 0 to 2 | Count the bugs, agree the order, re-state the rules. |
| 2 to 12 | Go through the bugs, highest severity first. About one minute each. Decide the outcome, the priority and the owner. The chair writes it down. |
| 12 to 14 | Review anything marked urgent. Does it need to start today? Does anyone have to be told? |
| 14 to 15 | Read back the decisions. Send the notes. |
If there are more than about ten bugs, the order matters. Take the severe ones first; the trivial ones can wait until next time, or be handled in bulk ("anything cosmetic goes to the backlog unless someone objects").
The five outcomes
Every bug leaves the meeting with exactly one of these:
- Fix now. Assign a developer and a target date. It goes into the current work.
- Fix later. It is real, and it is scheduled for a future release or sprint, with a priority.
- Needs information. Assign a person to ask the reporter a specific question, with a date by which the answer is needed. If there is no answer by then, close it.
- Duplicate. Link it to the existing bug and close it. A person does this; check the existing bug really matches.
- Not a bug or won't fix. Close it with a reason the reporter can read. "Works as designed, here is where it is described" is a reason; silence is not.
"Discuss further" is not an outcome. If a bug needs a long discussion, give it a separate slot with the right two people, and move on.
Rules that keep it short
- One minute per bug. The chair says "needs information" when time is up.
- No debugging in the room. Estimates only, as a rough size: hours, days or weeks.
- The product owner has the last word on priority; the developer has the last word on size.
- Every bug gets an owner before it leaves the meeting. An unowned bug is an undecided bug.
- Close with a reason. The person who reported it is waiting, and a reply costs one line.
- Same time, same day. Triage that depends on someone remembering to schedule it stops happening.
Notes template
BUG TRIAGE: [date] Chair: [name] Present: [names]
[Key] [Title]
Outcome: fix now / fix later / needs info / duplicate of [key] / not a bug
Severity: [level] Priority: [level]
Owner: [name] Due: [date]
Note: [one line]
Urgent follow-ups:
- [who] to tell [who] about [what]
Next triage: [date, time]Keep the notes in the tracker if you can, as a comment or a label on each bug, so the history lives with the bug. SnagRelay passes reports to Jira, Linear, GitHub, GitLab, Trello or Azure DevOps with the evidence attached, which keeps the "is this real?" question short; it does not decide severity or priority or run triage for you. Those decisions stay with the people in the meeting. For how to set the severity and priority fields, see the severity post linked above, and for deciding when open bugs block a release, see UAT exit criteria.
FAQ
How often should we hold a bug triage meeting?
Daily during a UAT round or a release week, and once or twice a week otherwise. Short and frequent beats long and rare, because bugs wait less.
Who should run bug triage?
A QA lead or project manager, with a product owner who can set priority and a developer who can estimate. The chair's job is to keep time, not to decide.
What is the difference between triage and a bug review?
Triage decides what happens next to new bugs. A bug review looks back at fixed or open bugs to learn from them, for example the causes or the escape rate. They are different meetings.
What should we do with bugs nobody can reproduce?
Mark them "needs information", ask the reporter a specific question and set a deadline. If the answer does not come, close the bug with a note that it can be reopened with the missing details. The post on bug reports that avoid "cannot reproduce" covers how to prevent them.