What Is Defect Triage?
Defect triage is the process of reviewing reported bugs, assessing their impact, assigning priorities, and deciding what action to take. The term “triage” comes from emergency medicine — sorting patients by urgency to allocate limited resources effectively.
In software, triage serves the same purpose: with limited development time, which bugs should be fixed now, which can wait, and which should be closed?
Meeting Structure
Frequency
- During active testing: Daily, 15 minutes
- Normal sprint: 2-3 times per week, 20 minutes
- Maintenance mode: Weekly, 30 minutes
Attendees and Roles
| Role | Person | Responsibility |
|---|---|---|
| Facilitator | QA Lead | Run meeting, keep time, document decisions |
| Bug Reporter | QA Engineers | Present bug details, answer questions |
| Technical Assessor | Dev Lead | Estimate complexity and risk of fixing |
| Business Prioritizer | Product Owner | Set priority based on business impact |
| Scribe | Any attendee | Record decisions (can be facilitator) |
Agenda
- Review new bugs (10 min) — walk through each new bug briefly
- Assign priorities (5 min) — agree on severity/priority for each
- Allocate (5 min) — assign to developers based on component ownership
- Review stale bugs (5 min) — check bugs with no update in 7+ days
- Metrics (2 min) — quick look at open bug count, trend
Triage Decision Framework
For each bug, the team decides one of:
| Decision | Criteria | Action |
|---|---|---|
| Fix Now | Critical/High severity, blocks release | Assign to developer, target current sprint |
| Fix Next | Important but not blocking | Add to next sprint backlog |
| Defer | Valid but low impact | Move to future release backlog |
| Won’t Fix | By design, obsolete, or cost > benefit | Close with justification |
| Need Info | Cannot reproduce or unclear | Return to reporter for details |
| Duplicate | Same as existing bug | Close, link to original |
Running an Effective Triage
Do:
- Time-box to 30 minutes maximum
- Prepare — review bugs before the meeting, not during
- Focus on priority decisions, not technical debugging
- Document every decision with rationale
- Review deferred bugs periodically to prevent endless backlog growth
Do not:
- Debug bugs during triage — that is a separate activity
- Let one bug consume the entire meeting
- Allow emotional arguments — use data and impact assessment
- Skip the meeting when there are few bugs — check metrics instead
Exercise: Triage These Bugs
You are facilitating a triage meeting. Triage these 6 bugs (release deadline: 5 days):
- BUG-401: Login page crashes on iOS Safari 17 (affects 15% of users)
- BUG-402: “About Us” page has a typo in the second paragraph
- BUG-403: Payment amount rounds incorrectly for 3-decimal currencies (JPY, KRW)
- BUG-404: Search autocomplete suggestions load slowly (3 seconds vs 0.5s target)
- BUG-405: Admin report export generates empty CSV files
- BUG-406: User avatar upload works but the preview shows the wrong orientation for HEIC files from iPhones
Solution
BUG-401: Fix Now. P1/S1. Crash affecting 15% of users is release-blocking. Assign immediately.
BUG-402: Defer. P4/S4. Trivial cosmetic issue. Fix when convenient, not worth risking the release.
BUG-403: Fix Now. P1/S1. Financial calculation error — incorrect amounts mean potential legal and financial liability. Even if rare currencies, this must be correct.
BUG-404: Fix Next. P2/S3. UX degradation but not blocking. Schedule for the sprint after release. 3 seconds is slow but functional.
BUG-405: Fix Now. P2/S2. Admin feature is broken, not user-facing but blocks internal operations. Fix if time permits in current sprint.
BUG-406: Defer. P3/S3. HEIC is iPhone-specific, preview-only issue. Upload itself works. Fix in next sprint.
Tracking Triage Decisions
After each meeting, update Jira/tracker with:
- Priority and severity assignments
- Developer assignments
- Target sprint/release
- Decision rationale in comments
- Any “Need Info” items flagged for follow-up
Key Takeaways
- Triage meetings review, prioritize, and allocate bugs — they are not debugging sessions
- Keep them short (15-30 minutes) and focused with the right people in the room
- Use a consistent decision framework: Fix Now, Fix Next, Defer, Won’t Fix, Need Info
- Document every decision with rationale — “we deferred it” without “because” is insufficient
- Review deferred bugs periodically to prevent backlog bloat