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.

• To prioritise — Inicial state;

• Icebox — Should be fixed, but not a priority;

• For Next Delivery — Should be discussed in the next planning.

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).

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

Periodic triage

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. 🚀