How to use bug triaging to save your teams' time

The focus should be on creating a process that protects the team’s productivity while ensuring the product’s reliability. But how?

The team is focused and working hard in the next release when suddenly a bug is reported. The team immediately jumps to it but soon after realizes: The bug shouldn’t be that important.

This problem affects too many teams! It’s very easy to report bugs in a tool such as Slack without any prioritization or steps to reproduce them. Thus, the responsibility of analyzing and prioritizing these are left in the team’s hands. This has a huge impact on the team’s time and effort, which is then reflected in their focus and productivity. Therefore, the focus should be on creating a process that protects the team’s productivity while ensuring the product’s reliability. But how?

How to reduce the impact of bugs?

The first step is to introduce a triage process that everyone understands and complies with. Here’s an easy way to get started.

Split the bugs into three different actions:

A. Immediate action (Blocker);

B. No action for now (P1, P2, P3);

C. Ignored.

The bugs type A and B should be split into “To prioritise”, “Icebox” and “For Next Delivery” columns.

Every time a bug is found, the board needs to be updated with a new ticket. This should happen only on the board, as it’s ideal to have a central and unique place to report bugs (Bug triage board).

The following process is applicable in Agile contexts like SCRUM, but using KANBAN as an example here.

Bug Triage Board

Depending on the bug’s urgency and importance, the bug can be tackled right away or on the next delivery (or Sprints if you’re working with them). This should be discussed between the whole team during the planning.

The board alone doesn’t do the work. There should be a process to take action on it — How?

Managing Bug Triage

Reactive triage

— A Bug occurs and someone needs to stop working to check if the priority is A (Blocker), or if it isn’t that urgent/important, B (P1, P2 or P3) and can be planned for future delivery.

As an example, if in an e-commerce platform the checkout is not working, a new ticket should be added on the project’s board, prioritized as an A (Blocker) and tackled right away.

Delivery Board example

However, if a bug is harming the product’s performance and business directly, the planning owner (e.g. Product Owner) should attribute a priority from P1 to P3 and discuss with the team when the planning time arrives. Again, good prioritization and thorough description are very important. This way the team know’s when it should be tackled and has as much information as possible about the issue (e.g. OS, browser, steps to reproduce), making their work more efficient.

Periodic triage

- Teams should use tools to monitor the product’s reliability and code performance  -  such as Bugsnag, Rollbar, Sentry or any other. When something is reported on these tools, the bug should be pushed into the triage board and managed as explained above. The bug can either be left on the triage board or added to the current delivery, depending on its prioritization. It can also be ignored (C.), and in this case, should be removed from the tool and no board action is needed.

With the above in mind, here’s an example of a process used on our processes at Pixelmatters:

  1. Create a bug triage board;
  2. Add a tool to scan the project’s code, and if possible, create automation to connect the tool with the board (example: JIRA and Bugsnag);
  3. Integrate the tool into the team’s communication channel (e.g. Slack);
  4. Define who is responsible to check the tool’s automated report, prioritize its findings and add the tickets to the bug triage board;
  5. Only share the bug’s ticket link on the project’s communication channel if it’s an A (Blocker);
  6. During each planning, the team should look into the bug triage board and decide which bugs should be addressed.

With all the above data in mind, the process suggestion should look like the following:

Bug Triage and Delivery process

The goal here is to have the team 100% focused on the delivery, knowing that if any notification arrives on the team’s communication channel, it’s surely urgent and should be given attention. With the tickets prioritized and all needed information included, the team will then have all the means to swiftly tackle the bug. 🚀

Follow Pixelmatters on Twitter, Facebook, LinkedIn, and Instagram.

André Silva
Engineering Manager