How many open bugs are in your backlog? 100? 1000?
And how long have they been there? A week? A month? Years?
Why is this happening? No time? Need to prioritize other tasks? "We will implement all urgent features right now, and then we will definitely have time to sort out the bugs"?

… Some use a Zero Bug Policy, others have developed a strong bug management culture (regularly updating their backlog, reviewing errors when functionality changes, etc.), while some raise magicians who write without bugs at all (unlikely, but maybe that happens too).

Today I will tell you about our solution for clearing the bug backlog — the "Bug Clearing House" project.

How did it all begin?

While reviewing the ever-growing backlog of open bugs once again, we reached a boiling point. We couldn’t continue like this, and decided to reduce it at any cost. The idea was obvious, but how to do it? We agreed that the most effective way would be to hold an event similar to a hackathon: pull teams away from their everyday tasks and allocate one working day for addressing only bugs.

We outlined the regulations, put out a call, and started waiting. There were concerns that few would be willing to participate, very few, but the results exceeded our expectations — a total of 8 teams signed up (though at the last moment, 3 dropped out). A whole working day was allocated on Friday for the event, and we booked a large meeting room. Lunch was organized from the office cafeteria, and we added cookies for snacks.

Implementation

On the morning of Day X, we gathered all interested participants in the meeting room and held a brief briefing.

Main rules:

• a team consists of 2 to 5 members, with at least one being a QA;
• bugs must be resolved by a team member according to all internal production standards;
• each team must have at least one closed bug requiring code fixes;
• only old bugs can be fixed (bug creation date < start date of the clearing house — 1 month);
• points (from 3 to 10) are awarded for fixed bugs based on severity (to prevent cheating, severity cannot be changed after the date of the Bug Clearing House is announced);
• 1 point is awarded for closing irrelevant, non-reproducible bugs.
• The audit team monitors compliance with all rules, which revokes points for reopened bugs.

Other details

• We didn't restrict anyone in choosing their location: they could either stay at their desk or sit with everyone in the meeting room, where they weren't distracted and could feel the intensity of the competition.

• To support the competitive spirit, a leaderboard was displayed on the big screen, and a text broadcast of the battle was continuously running in the Slack channel. Points were counted using a leaderboard that was updated via webhooks.

Leaderboard

• The audit team monitored compliance with all rules (based on experience, 1-2 people are enough for this).
• An hour after the Bugathon ended, the verified results were announced.
  The winners received a gift certificate for a bar, and all participants received a souvenir (keychains with 'bugs').

Results

In the last six months, we have held three Bugathons. What have we achieved?

• The average number of teams was 5.
• The average number of processed bugs was 103.
• The average number of irrelevant/unreproducible bugs was 57% (and this trash constantly caught our eyes and terrified us with its quantity).

The moment of announcing the results

And now the answer to the most tricky question that everyone loves to ask: 'So how many new bugs did you create?'.
Answer: no more than 2% of all processed.

Feedback

After conducting the Bugathons, we collected feedback from participants. Here are the responses to the question 'What did you like most about the participation process?':

• It's really cool to sort through the backlog with such motivation! Usually, this is a very dull process; we need to do this periodically).
• Excitement, cookies.
• This is a long-awaited opportunity to fix those small things that are not critical but need fixing.
• I liked that we could finally fix old, unpleasant bugs outside of the sprint since there is never time for them, as there will always be higher-priority tasks. We managed to gather all the necessary people in one place (for example, we had a DBA in our team), and collectively discussed the relevance of the reported bugs and the technical feasibility of fixing them.

Conclusion

Bug hunting is not a cure-all, but it is a viable option for reducing bug backlogs (in different teams by 10 to 50%) in just one day. We successfully launched this initiative thanks to motivated team members who care about the product and the satisfaction of our users.

Wishing everyone less bugs and more goodness!

Source: habr.com