How many open bugs do you have in backlog? 100? 1000?
And how long they lie there? A week? Month? Years?
And why is this happening? No time? Need to do more priority tasks? "Now we are implementing all the urgent features, and then there will definitely be time to deal with bugs"?

... Some people use the Zero Bug Policy, someone has a well-developed culture of working with bugs (they timely update the backlog, review errors when changing functionality, etc.), and someone grows wizards who write without any bugs at all (unlikely, but maybe it happens).

Today I will tell you about our solution for cleaning backlog of bugs - the project “Bagodilnya”.

How did it all start?

Once again, looking at the ever-increasing backlog of open bugs, we reached the boiling point. It was impossible to live like this anymore, we decided to cut it at any cost. The idea is obvious, but how to do it? They agreed that the most effective way would be an event similar to the hackathon: to tear off teams from everyday tasks and to allocate 1 working day to handle only bugs.

Prescribed the rules, threw a cry and waited. There were fears that there would be few, very few, who wanted to, but the result exceeded our expectations - as many as 8 teams signed up (although at the last moment 3 merged). We allocated a whole working day for the event on Friday, booked a big negotiation. Lunches were organized on the basis of an office canteen, cookies were added for snacking.

Implementation

On the morning of Day X, everyone gathered in the meeting and held a brief briefing.

Fundamental rules:

• in one team from 2 to 5 people fight, at least one of them is QA;
• Bugs must be closed by a member of the team for all internal production standards;
• each team must have at least one closed bug that requires fixes in the code;
• Only old bugs can be fixed (the bug creation date <the start date of the bag-maker is 1 month);
• for corrected bugs, points (from 3 to 10) are awarded depending on the criticality (so that there is no cheating, it is impossible to change the criticality after announcing the date of the Bagodeling);
• for closing irrelevant, non-reproducible bugs accrue 1 point;
• Observance of all rules is monitored by an audit team, which cancels points for rediscovered bugs.

Other details

• We did not limit anyone in choosing a location: we could stay in the workplace or sit with everyone in a meeting in which the guys were not distracted and there was a feeling of passion.

• To maintain the competitive spirit, a rating table was displayed on the big screen, and a text translation of the battle was constantly going on in the slack channel. For counting points used leaderboard, which was updated through webhuki.

Leaderboard

• Observance of all rules was followed by the audit team (by experience, for this purpose 1-2 people are enough).
• An hour after the end of the Bagodelni, the rechecked results were announced.
  The winners received a gift certificate to the bar, and all participants received a souvenir (charms with “bugs”).

results

Over the past six months, we have already spent three Bagodelni. What we got in the end?

• The average number of teams - 5.
• The average number of processed bugs is 103.
• The average number of irrelevant / non-reproducible bugs is 57% (after all, this garbage constantly messed up eyes and frightened with its amount).

Moment of announcement of results

And now the answer to the most tricky question that everyone likes to ask: "And how many new bugs have you planted?".
Answer: not more than 2% of all processed.

Reviews

After Bagodelen we collected feedback from the participants. Here are the answers to the question “What did you like most about the participation process?”:

• Very cool to disassemble backlog with such motivation! This is usually a very dull process, it is necessary to carry out this periodically).
• Excitement, cookies.
• This is a long-awaited opportunity to correct those little things that are not critical, but I want to rule.
• I liked that you can finally fix old, unpleasant bugs outside the sprint, there will never be time for such since there will always be tasks with higher priority. We managed to gather all the right people in one place (for example, we had dba in our team), collectively discussed the relevance of the set bugs and the technical ability to fix them.

Conclusion

The cottage-house is not a panacea, but quite a viable option to reduce backlog of bugs (in different teams from 10 to 50%) in just one day. We have this event took off only thanks to the motivated guys who support the product and care about the happiness of our users.

All good and fewer bugs!