Bug bash and Bug Squash

Recently I've been working on a redesign of a community site, we've been approaching this in an agile way, working on a group of pages each sprint, and then showing them to the stakeholders (and where possible real users). We're a pretty long way through the process now, and during this time we've tweaked some design and user experience decisions, so a few weeks ago thought it was a good time to take a step back and review what we have built so far.

I'd read a little about bug bashes, and after speaking with a couple of members of the team set up a "Bug bash and Bug Squash" day. The idea was simple, get as many of the team and stakeholders together as possible and review the site, listing every issue (however small!) and then fixing as many as possible in the same day. To allow the team to concentrate on this we booked out a meeting room (in another building) and asked everybody to bring a laptop and a device or two, so the whole team could be together without too many other distractions.

We kicked off at 10AM, this gave people time to find the room, settle down and deal with emails before we got into the day properly, with a simple brief - use the site and raise anything that was wrong. If somebody wasn't sure if something was correct or not then as most of the stakeholders were at the same table a quick discussion could be had before moving on. A pack of index cards were in the middle of the table (along with plenty of biscuits and cake) and these were then put on the wall as people found issues.

We started at quite a pace with half a dozen issues on the wall in the first few minutes! We carried on for around 2 and a half hours, discussing things we weren't sure of and adding the issues to the wall, before breaking for a team lunch. By the end of the morning we had identified around 60 (mainly minor) issues!

Kanban Board

After lunch we reviewed the issues and split them into 4 categories - less than 30 minutes to fix (30 issues), less than an hour to fix (8 issues), longer to fix (10 issues) and requires more discussion (12 issues). Everything in the last two categories was ignored for the rest of the day and will be added to the backlog to be looked at as soon as possible. We had a quick discussion about how to prioritise the issues in the first two categories and decided to just try and fix as many as possible, we setup a quick Kanban board with WIP, Ready for test and Fixed columns. The 5 developers took an issue each and moved it to the WIP column and got on with fixing it, moving it to Ready for test when available on our test environment for our tester and stakeholders to review, before being moved to fixed.

We decided to relax our process for the afternoon, which I think was a key thing to allow this to work. We use git and usually enforce all changes to be made via a Pull Request which must be reviewed by another developer. As we were trying to fix as many issues as possible in a small amount of time, and the low risk nature of the changes we agreed to remove the pull request requirement for the afternoon.

About 2 and half hours later when we finished for the day we had fixed and tested 23 of the issues!

Lessons learnt

We did a retrospective as a team a week or so after the event, and the whole team was very positive about the whole day, and eager to do one again.

Kanban BoardRelaxing process is important for these small issues - a lot of the issues we found would be ranked as minor when put alongside other tasks on the backlog, but are no less important! It is often these small things that distract from the good done with the bigger features. The process that surrounds bigger features or issues (creating a story or bug with a full set of acceptance criteria, prioritising in the backlog, estimating in planning, creating a feature branch and pull request and reviewing), add a large overhead to issues that only take a few minutes to fix, these are great when developing bigger features, but relaxing this and focusing only on these issues for a day is a really efficient way to handle them.

Being located together for the day (we're usually spread over a couple of floors) was great in terms of productivity, but also good for team spirit and got everybody chatting. The change of location and snacks also helped this (although there was a request for healthier snacks next time!).

The main negatives were around the infrastructure available and the amount of time testing. The wireless internet connection wasn't great and we didn't have enough network cables handy to deal with this. The balance of time testing/fixing was also raised, as potentially too much time testing.

Whats next

We still have some of the bugs left to address, and hopefully will be working our way through those in the next week or two, with the new design due to go live in a couple of weeks time.

We've also started to pencil in another day just before Christmas to pick up any remaining issues. We'll be much more careful about network availability next time, and probably reduce the testing time in the morning, although think this is still a very valuable part of the day.

  • Post