1.6Defect Triage

Triage is the process of reviewing new bugs and deciding what to do with them. Without triage, bug reports accumulate in the "New" status for weeks. Developers complain that QA files bugs nobody looks at. QA complains that developers ignore their findings. Triage breaks this cycle.

The Triage Checklist

For every new bug, the triage team asks:

1. Is it reproducible? If not, ask the reporter for more details or try to reproduce yourself.
2. Is it a duplicate? Search existing bugs before creating a new one. Use JQL: project = SHOP AND type = Bug AND text ~ "coupon expired".
3. What is the severity? Assess the technical impact using the severity scale.
4. What is the priority? Consider business impact, affected users, and available workarounds.
5. Who should fix it? Assign to the right team or developer based on the component.
6. When should it be fixed? This sprint, next sprint, or backlog?

The Daily Triage Meeting (15 Minutes)

Many effective teams hold a quick daily triage meeting:

• Review all bugs created in the last 24 hours
• Confirm priority and severity
• Assign owners
• Link to related stories or epics
• Flag any blockers for the sprint

The meeting should take no more than 15 minutes. If it consistently runs longer, you are either filing too many bugs or your triage process needs streamlining.

Pro Tip: Designate a rotating "triage lead" from the QA team. This person pre-reviews all new bugs before the meeting, suggests priorities, and ensures each bug has sufficient information. The meeting then becomes a quick confirmation rather than a lengthy discussion.