Bug Fix Day!
After a couple of iterations our software started to show some wear and tear. With all fat-GUI clients you always have some behaviour that isn’t exacly what you want, there are always glitches. More and more (Scrum) iterations followed and more and more glitches started accumulating in the application. These glitches are sometimes hard to fix and/or hard to reproduce, and they never made their way to our backlog.
How do you solve this?
“Bug Fix Day” concept
To improve the quirkiness and general impression of our application, as well as the teamspirit, I decided to hold a competition! This is how we did it:
The teams
- Take everybody, testers, project managers and of course the developers. Mix and create small groups of three (maybe four) people with a mixed skillset.
- Create a jury, in our case the two product-owners and a GUI-expert.
- One day the teams compete against eachother.
The boards:
You’ll also need two board:
- Create a BugBoard with (on Post-its) all known existing glitches and bugs which need fixing.
- Create a TeamsBoard with a list of all the teamnames (make them come up with cool names!)
Jury:
The jury (product owners) must assign points to all the known bugs on the BugBoard, ranging from 1 point to 10 points.
- 1 point: minor importance
- …
- …
- 10 points: important! fix asap
Scoring points
Now the teams can do two things:
Fix a bug
Take a Post-it from the BugBoard and paste it behind your teamname on the TeamsBoard. There is a maximum of 1 (!!) Post-it. Your team can only claim and work on one bug at the time. While you are doing this, nobody can work on that same bug.
When you have implemented a fix for the bug, commit it, let the jury check the result. Once the jury has verified the fix, you’ll get the assigned points!
Find a bug
If you want you can also scan the application for new glitches and bugs. If you have found a (repeatable) bug, document it on a Post-it and give it to the jury. If they can reproduce the glitch/bug, they’ll assign points to the bug. For finding the bug you’ll receive half the bug’s points.
Extra rules
There are a couple of extra rules:
-
The teams can only work on one workstation. You’ll have to pair up and work together. This will enforce the teams to look at each others code and learn.
-
If you break the (continuous) build, you’ll lose points. For every minute the build is not green, a point is deducted from your team’s score.
-
At the end of the day all the teams have to present their fixes.
This will show everybody a couple of things:
- How was the bug fixed?
- What was wrong?
- How could it have been prevented?
- Bonus points! To make it even more exiting we’ve introduced bonus points. Try to come up with original ideas! This is our list:
- Most impressive presentation: 2 points
- Hardest bug to fix: 2 points
- Best team name: 1 point
- Most original found bug: 1 point
Possible problems
Of course there are possible problems you want to avoid:
- People saving up bug-fixes
- People introducing bugs, solve on bug fix day.
- People not telling about glitches, report them on bug fix day.
We haven’t seen this behaviour yet, but you’ll have to trust the developers. Our team has enough professionalism to not have this problem (yet?).
Results
When I suggested this idea to our product owners they were very enthusiastic. About a week later we had our first Bug Fix Day and the results are very impressive.
- All of the 10-point (most important) bugs had been solved
- Most other bugs/glitches had been resolved
- Despite people actively abusing the system, not a lot of new glitches could be found (in contrary to our impression).
- Developers loved it, teamspirit was very high. It was fun to see the competitive instinct during that day.
- Our team won, and got a very good lunch as surprise first prize (yay!).
Other idea’s this concept could work for:
- Performance Fix Day (improve performance)
- Funny Features Day (build new features into the application)
- Other ideas…?
If you decide to hold a Bug Fix Day at your company, I’d love to hear about the results!