<Sing title to the melody of the batman theme song>
In the company I just left we had a weekly bugslot to stay on top of defects: 2 hours every week during which all developers fixed bugs at the same time. It’s not a perfect solution but solved a number of pressing problems:
- Discouragingly high number of bugs – accumulated over a long time
- No overview / documentation / communication of what was fixed, what deployed, and what left to fester
- We had no bugtracker. (The developers never reached agreement, which one to use.)
- The same bugs appeared again and again, their symptoms often fixed by different people, so that no one recognized patterns
- No order given in which to fix
- Decision if and what to fix fell back on each individual dev. And as bugfixing took time away from the sprint and the team commitment…
- About 30% of all developers were new hires, yet unfamiliar with the systems
- The systems weren’t documented, so the new devs had no chance to fix bugs on their own. It was left to the “old” ones, who groaned under the additional workload
The situation in my new workplace is similar enough that I suggested a bugslot as well. It has a good chance of doing the trick again.
How exactly does a bugslot work?
- 2 hours each week for fixing (non-urgent) bugs
- At the same time every week
- All developers at the same time
- Pick a week day and time that most developers will be there. Lunch time’s holy, though
- Before: Order the bugs. What needs fixing first is first in line
- Can be done by product owner, stakeholder such as costumer support, …
- Publish the list highly visible
Continue reading


