Template

Bug triage template

Go through the new bugs, decide how serious and how urgent each one is, give each an owner — and close the old ones nobody will ever fix.

30 minutesFor A product manager, a tech lead and someone from support or QAAgenda room
Change the agenda first

The agenda, with a time for each part

  1. New bugs since last time12 min
    • Can we reproduce it, and how many people does it affect?
  2. How serious, how urgent8 min
    • Does it lose data, money or trust, or is it an annoyance?
  3. Owners5 min
    • Who looks at it, and by when?
  4. Old bugs to close5 min
    • Would we ever fix this? If not, why keep it open?

How the notes read afterwards

A made-up example, so you can see the shape. In a real call each line carries the words that were said and who said them.

New. Fourteen bugs; three duplicates closed.

Serious. Some invoices show the wrong currency — affects about 40 customers. Fix this week (Sami).

Annoying. The date picker starts on Sunday for UK users. Next sprint.

Closed. 23 bugs older than a year, in features we have since replaced.

Running it well

Ways to change it

During a launchDaily for fifteen minutes, new bugs only.
Big backlogOne extra session a month only for closing old bugs.

When to skip it. If new bugs are rare, look at them in sprint planning instead of meeting for them.

Questions

What is bug triage?

Reviewing newly reported bugs to confirm them, decide how serious and urgent each is, and assign an owner, so the most important ones get fixed first.

What is the difference between severity and priority?

Severity is how much damage a bug does; priority is how soon it should be fixed. A severe bug that almost nobody can trigger may still be low priority.

How often should bug triage happen?

Once or twice a week for most teams, and daily around a launch.

What happens in the room

Everybody joins from the link, with no account. The agenda sits beside the call and each item fills in with what was said about it, under the name of the person who said it.

More templates

Product discovery reviewThe team shows what it learned from customers this cycle — interviews, tests, numbers — and decides which ideas are worth building, which need more evidence, and which to drop.Design critiqueA designer shows work in progress and the group says, against the goal, what works and what does not — so the design gets better before anyone builds it.Feature kickoffBefore work starts on a feature: everyone who will build, test, launch and support it hears why it matters, what done looks like, and what is deliberately left out.Launch planning meetingA few weeks before a launch: who hears about it, in what order, through which channels, what each team must have ready, and the one date everyone works back from.Beta feedback sessionA conversation with a customer using something before it is finished: what they used it for, where they got stuck, what they would miss if it went away.Product councilThe leaders of product, engineering, design and the business decide together what gets built next and what stops, so teams are not pulled in different directions.Project kickoffWhy the project exists, what done means, and who owns what — agreed on day one.Sprint retrospectiveWhat went well, what did not, and the one or two changes you will actually make.

All 162 templates →

Try Meetful

Meetings that take their own notes

Free video meetings in the browser: every line of the transcript under the name of who said it, and the summary and action items when you hang up. Nothing to install — guests just open the link.

Try Meetful freeSee what it does