Triage

Avi Siegel

•

5 min read

What is triage?

Triage is a continuous activity performed on Agile teams where the Product Manager (PM) reviews incoming tasks assigned to the team. This ongoing exercise ensures that urgent work can be immediately acted on if necessary, and also serves to keep the product backlog in a clean state.

Most often, triage applies to customer-based requests, such as bugs and support requests. However, it also applies to any other tasks which are logged by anyone who isn’t the owner of the backlog. (The PM can effectively "triage" tasks that they create as they write them, but all tasks logged by others must be processed to ensure they are properly routed, detailed, and prioritized.)

What are the goals of triage?

The primary goals of triage are to:

  • Maintain sufficient knowledge of all tasks assigned to the team

  • Reroute tasks to more appropriate teams when necessary

  • Escalate urgent tasks into the current sprint or higher in the backlog, as appropriate

  • Keep the backlog clean and prioritized

What is involved in the triage activity?

As new tasks are logged in the task management system, they must be routed, detailed, and prioritized. These new tasks should automatically be placed into a triage area, so it is clear when new tasks are waiting to be reviewed.

Note that the purpose of a fast triage process is not to handle the work quickly, it is to determine if the work needs to be handled quickly. If it is indeed urgent, it can be escalated into a sprint or prioritized high in the backlog.

Review

At least daily, review newly created tasks. Most importantly, identify any potentially urgent items that may require immediate attention. This ensures that such tasks will be seen and acted on promptly.

Pro Tip: While it may be tempting to set up automated notifications for newly created tasks, this approach can often lead to notification overload. Instead of relying on notifications, establish a consistent routine for reviewing the triage area. For instance, consider setting up a daily reminder (such as a 15 minute repeating calendar block each morning) to ensure you remember to, and have time to, triage incoming tasks.

Reroute

Based on formal team responsibilities across the product, route any task which would be more appropriate for another team to that team.

When transferring ownership to another team, it is advisable to leave a comment in the task to 1) inform the new owner as to why the change was appropriate, and 2) ensure the new owner is aware that they are now the owner, so they can begin their own triage process.

Pro Tip: Create formal documentation regarding how ownership is split across the various product teams. This will serve as a useful reference when you are unsure where ownership should be transferred. It will also provide transparency and understanding, to reduce the chances that "hot potato" situations occur where no team wants to own a given task.

Archive

Some tasks being triaged will not need to be completed. Archive these tasks, and leave a comment explaining why they will not be acted on.

There are many possible reasons to archive a task - for example:

  • A "bug" which is in fact working as intended

  • A bug which will be fixed as part of other prioritized work (e.g., a new iteration of a feature)

  • A bug which cannot be reproduced (and thus cannot be adequately addressed)

  • Work that has already been logged in a separate task (in which case, before archiving, it would be worth linking the new task as a duplicate of the existing task)

  • A task that represents a feature request or idea, which should instead be logged in an idea tracker

  • A support request which can already be handled by an existing feature, and thus should be done by the user themself (which should be relayed to the user by the employee who logged the support request on behalf of the user)

Pro Tip: When archiving tasks, always provide a clear reason in the task comments. This helps maintain transparency, and also acts as an easy reference in case the issue resurfaces.

Refine

Tasks may be logged by colleagues outside of the team, or even by external users, who may be either less familiar with what information would be helpful to include, or less capable of collecting such information. Refine these tasks by adding or requesting pertinent information.

The necessary information will be dependent on the task type. For example, a bug report may need:

  • Reproduction steps

  • Expected vs. actual behavior

  • Impact and severity assessment

  • Screenshots or video recordings

  • Assignment of related product components

Pro Tip: Provide templates or documentation that help colleagues adequately describe the work being logged. They may be able to provide more helpful information if you simply tell them what information would be helpful.

Prioritize

Prioritize each task on the backlog. Higher importance tasks will be higher in the backlog, and lower importance tasks will be lower in the backlog. Truly urgent tasks may be escalated into the current sprint to ensure they are addressed quickly.

Pro Tip: Be objective when determining urgency, as any change in priorities can disrupt the flow of affected engineers; context switching is a real concern that negatively impacts productivity. E.g.: Must the bug truly be resolved right now? Can it wait until the next sprint? Does it occur frequently enough to even be worth the team’s time to resolve?

Who should perform triage?

Triage should be performed by the PM who owns the backlog. They are solely responsible for being familiar with everything on the backlog and determining priorities, so all work must go through them.

Best practices for triaging incoming tasks

  • Keep the triage area separate from the backlog. If triage effectively lives within the backlog (e.g., at the bottom), it is easy to miss tasks as they enter the system, meaning urgent tasks won’t get acted on urgently, and the PM will not be knowledgeable of tasks that live in the backlog (resulting in a messy backlog full of improperly prioritized tasks, as well as tasks which will never be completed).

  • Apply a triage process to all tasks, not merely bugs and support requests. For example, if an engineer logs a new infrastructure task, it should not automatically be promoted to the backlog; rather, it should first be reviewed by the product manager and/or engineering manager to determine if it is work that will actually be performed, and if so how it should be prioritized.

  • Establish clear criteria for task urgency and priority levels. This will ensure consistent, objective decision-making.

  • Communicate triage decisions and rationale to stakeholders. Transparency is key to keeping everyone aligned on priorities and performing the highest value work.

  • Set aside formal time to perform triaging of incoming tasks. Especially for product managers, calendars can quickly become full of back-to-back meetings. Give yourself space to stay on top of potentially-urgent incoming work. Even if you don’t have enough time for a full triage session, it can be beneficial to quickly review the triage list in an attempt to spot anything truly urgent.