Triage Meeting
Goal of the Meeting
Formal meeting where all the defects of the current Sprint are
discussed and prioritized.
Format
Development Team or Support Engineers demonstrates and explains
the defects to the rest of the Scrum Team.
Based on everyone’s input, the defects are organized and
classified into different categories.
In the Triage meeting we will discuss Severity, Risk associated,
Business Impact, Occurrence. The categories will play a factor
in the urgency of the defect resolution plan.
Attendees
The Development Team
The Scrum Master
The Product Owner
Representative (Tier 1-3)
The Development Team

Explain and demonstrate the defect






Focus on the root cause analysis
Provide an insight on the application areas impacted by the
defect
Provide details on complexity involved in fixing the defect
Assign the defects amongst themselves for fixing and
testing
A combined call is made as to whether the defect is
acceptable or should be rejected
Helps in prioritization of the defect.
Scrum Master
● Responsible for organizing the triage meeting
● Facilitate the meeting
● Take notes if there are any impediments that the team may
encounter for the defect fixes
● Checks that the meeting is time-boxed and does not deviate
from the focus
● Classifies the defects to defect Classes by assigning their
Priority and Severity.
Product Owner
● Major stake in Prioritization of the defects that would
determine how latest the defect can be resolved
● For the defects, having a medium priority, the Product
Owner can plan to place them in the Product Backlog to be
picked up for the subsequent releases
● Allows the team to understand how the business would be
impacted because of the defect
● The Product Owner takes on the end user’s perspective and
sentiments while discussing the defects.
The defect is rejected if it is found to be invalid. If the
defect is a valid one, then the team checks for the complexity
of fixing the defect and the business impact it would make if
left unresolved in the system.
During the call
As a team defect are analyzed and evaluated the bug for right
classification. Priority and Severity is assigned to the defect.
Product Owner along with the team determine what sprint cycles
the defects should be assigned/
Bug Severity Score
4 parameters used to generate a bug severity score which goes
into the report:
● Bug Type
● Impact
● Likeahood
● Workaround
In order to generate the bug severity score, we attached a value
to each answer, and weighted the scores for each section to get
a total score out of 100.
Bug Severity Score= Sum of (Bug Type, Impact,
likelihood & Workaround time)
Bug Type, Impact, likelihood & Workaround time must <=25
Bug Severity = 100 means FIX THIS BUG NOW and deploy it to
production in the quickest possible time. Drop everything and
get anyone to help. These go straight into the current Sprint.
Bug Severity >= 90 means do not do another release of this
product without fixing this bug first (it might not be live yet,
howver doing a release could make this a HUGE problem). These go
straight into the current Sprint.
Bug score >=80 means we need to tackle this bug in our current
Sprint, but we’ve still got a bit of time to fix this.
Bug Severity Types
P1 = Fix it now (=100)
P2 = Fix it soon (>=90)
P3 = We definitely should fix this one day (>=80)
Bug Type
Assign each defect a Value for each Bug Type on a Scale of 1-5
PARAMETER
MEASUREMENTS
SCORES
Bug Type
No User Impact
<=5
Visual Polish
<=5
Minor usability issue
<=5
Impairs usability in some scenarios
<=5
Major Usability Issue
<=5
Total
<=25
MEASUREMENTS
SCORES
Impact
PARAMETER
Trivial
Bug Type
5
Minor
10
Starts to hurt
15
Major
20
Critical
25
Likelihood: (how likely or % of users affected)
PARAMETER
MEASUREMENTS
Most unlikely (0–10% users)
Very unlikely (11–20% users)
Unlikely (21–30% users)
Kind of unlikely (31–40% users)
Likely (41–50% users)
Impact
SCORES
2.5
5
7.5
10
12.5
Most likely (51–60% users)
15
Very likely (61–70% users)
17.5
Almost sure (71%-80% users)
22.5
For sure (81–100% users)
25
Is there a workaround?
PARAMETER
Workaround
MEASUREMENTS
SCORES
Quite easy to get around the issue
<=5
Fairly obvious, but some users might not
get it
<=5
Less than ideal workaround, most users
won’t get it
<=5
No workaround
<=5
Fast workaround
<=5
Total
<=25