The Spike Board: A Quick Agile Solution for Managing and Visualising Tech Spikes and Bug Bashes

I’ve recently been fortunate enough to start working with as one of my clients, specifically with their home team, who deal with their home insurance site. These guys are fully awesome, and I’m having a really good time.

What I want to do with this post is share with you a way in which we reorganised one of our agile boards, in a way that you might find helpful.

CTM make heavy use of agile techniques, to the point where bugs are often not filed in any kind of tracker (we use Mingle, when we use anything at all), but instead appear as cards on the appropriate board. The past couple of days we’ve been doing a bug bash in the run up to a release of some new functionality, and we’d written all the areas that needed testing as a big list on one of the boards.

People would pick areas for testing, write their initials by them, and mark them as completed either by ticking or crossing them off the list. Bugs were written in a separate list at the bottom of the board in the order they were encountered. After some discussion, some items we decided we didn’t care about or postponed until later, both test and bugs.

As you can imagine the board’s starting to look pretty messy at this point. Not a problem for those of us who’ve been around the whole time, but a couple of the team had been out and, at the standup this morning, it became clear that our board wasn’t really doing a great job of communicating:

  • what we’d done
  • what was left to do
  • what we’d decided not to do
  • what each of the items (test areas and bugs) actually meant

Lightweight is good but we’d probably gone a bit too far in that direction and, in fact, there was quite a bit of confusion.

The net result is we had to go through each item one by one. It didn’t take absolutely ages, but it was somewhat time-consuming.

So… we decided to rework the board to make it clearer to anyone and everyone what was happening and where we were in the process.

Here’s what we came up with for the “work item” board, where a work item is either an area for test, or a bug.


The basic idea is that work items are written on cards and start in the top left under proposed. They then migrate either to rejected or done on the bottom right. Obviously cards can skip over stages – so they can move directly from proposed to accepted, for example.

Note that rejected doesn’t mean rejected for all time: it just means we’ve chosen not to do something in this tech spike.

Bug prioritisation was another issue so we came up with this, although we haven’t yet needed it. In future though, when bugs are found we can write them on cards and stick them on another board that looks like this:


The axes are severity on the left (high or low) and incidence (alternatively hit probability) at the bottom. Priorities are shown in red – we just pick off the bugs in priority order. It’s rough and ready but should make it easy to prioritise.

You can obviously choose different axes that are more relevant for you if you like. Likewise, if you have different states for your work items than we use, or you have more or less of them, go ahead and use them.

Bugs that we’re fixing then become work items (on different coloured cards) that go back on the work item board, probably going straight into accepted. We probably lift them directly from the bugs board and place them on the work item board – thus the bugs board only contains live bugs we’re not actively working on.

Work item cards look like this:


Everything apart from the title and name(s) are optional, to keep it as lightweight as possible. We could just use avatars instead of names – we all have little stickies with our chosen avatar on that we add to any cards we’re working on. For things that are done it might be handy to use names so we don’t need to create loads of avatar stickies for everyone.

The cards on the bug board would be similar, but just with a title and description (optional). Potentially we could transfer them from the bug board to the work item board when we start working on them so that (i) we’re not duplicating cards, and (ii) it’s easy to see how many outstanding bugs there are.

Here’s what our work item board now looks like:


(Note that we decided not to add everything we’d already done to the new board, which comprised around two thirds of the total work items, but we took a photo as a backup so we have a record of the areas we need to test for future releases, and we’ll use the new board layout in future instead of the vanilla list.)

As you can see, it’s easy to understand:

  • the state of work items
  • how much WIP we have
  • how much is done
  • how much is left to do

Hopefully some of you will find this helpful as well.

Leave a Reply

Your email address will not be published. Required fields are marked *