Triage

Along with the 4 recommended Scrum meetings, I usually include a Triage meeting in my implementation of the Scrum process. I thought I'd share some pointers on triage.

What is triage?

Triage is a quick meeting to go over new / incoming defects. In the meeting, we sort defects and set priorities on them. Triage is a good place to groom the minimum viable product backlog, so all the tasks - stories and defects are prioritized in a single list. 

Participants, Frequency, Duration:

I recommend having the Product Owner and the Scrum Master participate in the triage meeting. The team can be made optional attendees. Specific team members join the call if they have opened / are working on defects that need to be explained in detail. 

Frequency of triage meetings is dependent on defect inflow. I have found that I'm comfortable with triage of about 8-10 issues in a single session.

As with any meeting in Agile, it is important to time-box the triage activity. Triage is not a place to solve the issues, or fight about the defect's exact place in the backlog. Triage is a meeting for building quick consensus and clarity on what the issue is, and what release it really needs to be fixed in.

Scrub of defects before the meeting:

In order for the triage meeting to be productive, I spend some time looking at defects before the meeting. I look for several things in this time:

1. Duplicates - if an issue is a duplicate of something that is already in the backlog, clean it up.
2. Change project - if an issue is incorrectly opened against our project, or if I can quickly tell that it should really be assigned to another team, clean that up as well.
3. Comments - I take a little time to look at code to figure out some technical details about the defect. I write my quick analysis as a comment on the defect. This is intended to give a head-start to the developer who is eventually going to fix it. I also try to add some notes that will help set priority during the meeting.

Priority setting:

Priority calls are owned by Product Owners. However, most product owners I have worked with usually take suggestions from everyone involved. I recommend following the MoSCoW principle for priority:

1. Must have - these are defects that "gate" a release. They must be fixed in order for the minimum viable product to ship.
2. Should have - these are "high" priority defects, which should really be fixed for the minimum viable product release.
3. Could have - these are "medium" or "low" priority defects, which can be included in the release if there is time, or if they are really low hanging fruits.
4. Won't have - these are defects that the product owner decides not to fix. The reason for this is up to the product owner. For example - defects that are deemed corner cases, or defects that are needless nitpicking.

As a Scrum Master, triage meetings help give me some idea about what is in front of the team - defects and stories included. This helps me look at forest from the trees. Doing a scrub of defects for triage also keeps me in the loop on latest code changes that the team is making. This helps me be a better code-reviewer. I have found triage meetings to be immensely helpful.

Rate this post!

☆

☆

☆

☆

☆