BoardSnap is an iOS app that converts whiteboard photos into clean summaries and action items in about ten seconds. This bug triage template structures a team session where every open bug gets a severity rating, a priority, an owner, and a resolution decision — in one meeting, on one board.
Run bug triage weekly for active products in development, or immediately after a release when the bug volume spikes. It's also the right format after an incident — the bugs that contributed to the incident need triage before anything else gets fixed.
Budget 30–45 minutes for a weekly triage with under 20 open bugs. More bugs need more time — but if your triage session regularly exceeds 90 minutes, that's a signal the bug volume is outpacing your capacity to address it.
Write every open bug that needs a triage decision. Not the whole backlog — the bugs that are new, reopened, or in dispute. Write the bug ID or short name and the one-line description of the behavior. Skip bugs that are already triaged, assigned, and moving.
For each bug: severity 1 (crash or data loss), 2 (major feature broken), 3 (feature degraded), or 4 (cosmetic or minor). Severity describes the impact on the user — not how hard it is to fix. Write the severity next to each bug.
Priority is separate from severity. A S3 bug in a flow that 80% of users touch might be P1. A S1 bug that affects 0.1% of users might be P2. Priority = severity × user exposure × strategic importance. Write P1, P2, P3, or P4 next to each bug's severity.
For P1 and P2 bugs: write the owner and the expected resolution date. For P3: write the owner and the sprint it targets. For P4: move to the backlog and note it. Every triaged bug has a human and a timeline — or an explicit 'defer to backlog' decision.
A column on the right: bugs the team has decided not to fix in the near term. Write the bug and the reason (low impact, cost exceeds value, intentional behavior). This list prevents bugs from staying open forever without a decision.
Whoever facilitates writes the open bug list on the board before the meeting starts. Don't spend triage time reviewing the tracker — the bugs should already be on the board when people arrive.
Go through every bug and write severity first. This is largely objective — either the app crashes or it doesn't. Get severity consensus before debating priority. Mixing the two creates confusion.
Priority is the judgment call. For each bug, state the reasoning: 'This is S2 but it's in a flow that only 5% of users hit, so P3.' Write the priority. Move on. Don't over-debate — three minutes per bug maximum.
Every P1 and P2 needs a name and a date before the session closes. No exceptions. A P1 bug with no owner is not a P1 bug — it's a P1 bug in denial.
Go through the backlog of old bugs. For anything older than 90 days with no owner and no sprint target: make the call. Fix it, defer it officially, or close it. A long-lived untouched bug is not a bug — it's a decision you're avoiding.
BoardSnap reads the bug list, severity, priority, owners, and resolution decisions. The output is a prioritized bug list with P1s and P2s as action items, won't-fix decisions documented, and the triage dated.
Bug trackers are great at storing bugs. They're bad at making triage decisions in a room. A whiteboard triage session forces every bug to get a verdict — severity, priority, owner — before the meeting ends. There's no 'I'll triage it later' when it's on the board in front of the whole team.
BoardSnap captures the triage board in ten seconds. The decisions are documented before anyone opens their laptop to update the tracker. Drop the BoardSnap output into your weekly engineering sync as the triage record.
Weekly for active products in production. Biweekly or monthly for stable products with low bug volume. After any significant release, run an extra triage session within 48 hours to address the post-release bug spike before it ages into the backlog.
The engineering lead, the product owner, and at least one engineer who has context on the codebase. For a small team, the whole engineering team attends. For a larger team, the team lead represents engineering. Support attendance is optional but valuable for bugs that come from user reports.
Severity measures the impact of the bug on the user when it occurs. Priority measures how urgently the team should fix it relative to everything else. A bug that crashes the app for 0.1% of users has high severity and may have lower priority than a bug that shows wrong data to 100% of users on the main screen.
The free tier gives you one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat on every board you snap.
No exporting, no transcription. Snap the board, get the action plan.