I grew up watching shows like M*A*S*H, and Emergency!. Doctor and paramedic characters would perform triage of injuries and determine which ones were critical and which could wait. If you think about it, bugs in a feature are like injuries to your code, and when they are discovered, they too need to be triaged. Without triage, bug tickets can add time to your development process and even cause invalid fixes. Every development team should triage their bugs!
Just What Does a Triage Team Do on a Development Team?
How many times have you worked on a bug that says something like “this feature is broken”? You might think this is an exaggeration, but it’s really not too far off. Especially if your team conducts bug bashes with users who don’t normally write tickets. This will either start a round-and-round process of different team members clarifying the ticket, or worse, a developer will take it upon him or herself to fix what he or she THINKS is implied. All of this is a time suck to the team. On the other hand, how many times have you wondered why some tickets are being worked while more critical tickets are just sitting there? How frustrating is that? This happens frequently if tickets are not prioritized and put into the backlog. A good triage team prevents all of this!
They will:
Review Tickets for Best Practices - Bug tickets should be written with enough information to identify the issue, plus steps to reproduce, and anything else that might be useful. The triage team will verify that the tickets have all the necessary information, or return to the originator to clean the tickets up. They will also apply their knowledge about the specific feature and other existing tickets to add valuable insights, and link to related issues.
Assign Severity and Priority - Tickets are often misclassified by their creator. The triage team might determine that a ticket labeled as critical is actually not so bad due to known workarounds or business needs. Or the team might find low-priority tickets that should be worked on immediately. The triage team also usually recommends whether a ticket needs to be pulled into a sprint.
Remember, this is a quick triage of tickets, so you want to keep the process nimble. An experienced team can usually handle a ticket in less than a minute. They don’t even need to leave their desk if they make use of online meeting rooms.
Who Should Triage?
The purpose of the triage team is to review bugs as they come in. Ideally, the people reviewing bugs have the power to make prioritization decisions, and are also familiar with the features. Strong subject matter expertise helps, along with knowledge of best practices and deliverable schedules. For a normal triage team, you would want to include:
Product Owner - helps with prioritization
QA Representative - familiar with bug ticket best practices, and intimate with the bug queue to help identify duplicate and related tickets.
Development Manager - good to have so that the team can understand the reasons behind prioritization issues.
While a triad of representatives is optimal, the role can be handled by a smaller team if needed. The key is to have decision-making ability, and knowledge of ticket best practices. Don’t make the team too large though, as you want to make things quick and easy.
When Do We Triage?
Many factors influence when triage becomes necessary. Some teams do triage on a regular basis, even daily. Others triage on demand. What factors determine when to triage?
Triage Team Availability - If you don’t make triage a calendar event, you might not be able to pull together the necessary players to make it happen.
Volume of Tickets - Are there a lot of tickets coming in daily? (You don’t want to overload the triage team.)
Timeliness - tickets can grow stale, or may be picked up by a developer before they are triaged. The creators might move on to other tasks. The sooner you identify issues with tickets, the more likely they can be cleaned up. If you were to ask me about a ticket I wrote two weeks ago I more than likely don’t have the data for the scenario setup to reproduce, or have the steps fresh in my head.
Release Schedule - As your release date approaches, it’s wise to increase the frequency of the triage. The shorter the schedule, the sooner you are aware of urgent tickets, and you can react more quickly.
Sprint Planning - if nothing else, try to do triage before a sprint planning meeting so that the sprint and backlog queues are addressing the highest priorities.
As you can see, triage can take place on the fly or on a regular basis — whatever the situation and the team deems is right.
So Let’s Get Triaging!
The sooner you start triaging, the better! Not only will your developers and QA teams appreciate complete bug tickets, but product owners will have a deeper insight into the state of the system. With this knowledge, immediate and future sprint planning will be much, much smoother! Joe Nolan is the Mobile QA team lead at Blackboard. He has over 10 years experience leading multinationally located QA teams, and is the founder of the DC Software QA and Testing Meetup.
