If you know even a little about Agile, you’ll have heard of the idea of using index cards for managing requirements. It might seem like a trivial concept, but I’ve had some unexpected successes with index cards recently, so I thought I’d share them with you.
Here’s the concept. Now, brace yourselves, because I don’t want to lose you in the detail here…
- Get some index cards, and a pen.
- Write each requirement on a separate index card.
- Watch the magic!
OK, I admit I am simplifying things somewhat, but really that’s the bare bones of it. If you read agile literature, you will find details on what format to write your requirement in (a “user story”) and also how to capture your acceptance criteria on the reverse of the card. But for me, the real magic comes simply from using index cards, rather than the actual words written on them. I’ll try to explain why.
Index cards are all about collaboration. You can lay them out on a table, or stick them up on a wall, and the people in the room can pick them up, move them around, put them in order, hold them and talk about them, scribble notes on them, do whatever they want with them.
Flip charts, whiteboards, projected computer screens – they’re all good for collaboration. But index cards are even better!
You can write anything on an index card, very easily. You can put words, pictures, numbers, colours, anything you like. There are no rules, so long as what’s added is adding value. It’s surprising what techniques a group of people can come up with when working with a set of index cards. Perhaps the requirement priority gets written in red in the top-right corner. Maybe “must have” requirements get a blue star. Maybe the colour of the writing indicates the functional area.
You can also organise the cards in any way you like. You might organise them by priority, or by which order you want to deliver them in, or in inter-dependent groups.
This is a real subtle one, and is possibly where most of the magic lies. Have you ever noticed how users become more engaged in a workshop if you can somehow bring the concepts to life? For example, a clickable HTML prototype of a user interface is so much more engaging than static screen shots, even though they look identical. There’s something engaging about the dynamic element to the prototype. The same is true of index cards. Because they are real, physical things that can be picked up and waved about, stakeholders seem to be much more engaged in the process.
One of the best uses I have found for index cards is to prioritise requirements. In the past, I have used a spreadsheet for this – one row per requirement and a column for the priority (whether it be high- medium-low, MoSCoW or numeric rank). These sessions can be really dry. But do the same thing with index cards and suddenly the process becomes a lot more…well, a lot more fun, for one thing. And when people are enjoying the process, they do a better job of it. It’s all about the “touchy feely” factor mentioned above.
Requirements and task management
If you are working on an XP project, then the idea is that you have all your index cards stuck up on a wall (the “card wall”), and the position of each card shows where it is in the delivery lifecycle (under headings like “backlog”, “in development”, “ready for test”, “in test”, “ready to deploy” and “live”). Sometimes, developers or testers take the cards away from the wall when they are working on them – on other projects they might attach their name to the card on a sticky note to show ownership.
The key point about the card wall is that it is very visual – it’s an information radiator – the team can stand around the wall and discuss progress with reference to the things they are working on. At all times, everyone can see the “project plan” from where they are sitting or working.
Index cards are the absolute antidote to processes and tools. Over the past few decades, methodologists and tool vendors have delivered ever more sophisticated processes and tools, refining all the time to cover edge cases and to generalise across different project profiles. I’ve worked with a few requirements management tools over the years and with hindsight I wasted a ridiculous proportion of my time just dealing with the technology – either in formal or informal training, or in find the best way to work within the tool or how to work around the limitations of the tool, or dealing with tool defects.
Using index cards directly after being chained to a requirements management tool is like being set free from a ball and chain! It’s more liberating than swimming naked (have you ever tried it? You should!). All of a sudden you are focussed 100% on the actual requirements and not on the delivery vehicle.
Alright, alright, I can hear it coming already. There are obvious downsides to index cards. You can’t edit them. They’re more difficult to transport (especially if you want to keep them in formation). You can’t email them (you can of course photograph them and email the photo, but then they are no longer index cards!). In summary, they are great for local teams in a single room, but don’t scale well geographically.
The most common work-around to these problems is to take a hybrid approach – whereby the cards are dual maintained in some electronic format. I’ve done this in two ways – one was to use a drawing tool (such as MS Visio), which is quick and easy. The other was to use a purpose-built agile requirements/project management tool, such as Greenhopper or Mingle. I’ve used Mingle, which works quite well, and also had other bells & whistles like burn-down charts, but there is something ironic about using virtual index cards – a key element of the “magic” is lost.
I’ve used index cards a number of times recently to prioritise requirements. Usually, the task at hand is to decide, “what are we going to build in this next phase/increment of work”, from a list of candidate features.
What I typically do is come to the workshop armed with the feature list (in a spreadsheet), some blank index cards and a few marker pens.
We work our way through the feature list. For each feature, we have a brief discussion on what it is (doesn’t have to be too detailed at this stage – the details come later), and then I write the feature name on a card and we place it somewhere on the table – with the highest priority features at one end and the lowest at the other. Each new card we add to the table is placed relative to the others, and by the end we have all the cards in “priority” rank order.
Then we take a step back and look at the cards in the round and start talking about what order we might deliver them in. We look at interdependencies and logical groupings, and move them around until we have “delivery sequence” order (which is often different from pure priority order).
These workshops usually take an hour or two, and by the end of it we have a clear view on what the next things are to work on – and, importantly, everyone in the room is engaged and agreed.
One of my stakeholders commented recently that she actually looks forward to my workshops – she finds the process so much more enjoyable than the usual dry sessions she’s used to. Another stakeholder, new to the process, was quiet for the first 20 minutes of a session, and then suddenly exclaimed, “I’ve just realised what you’re doing here! You’re actually prioritising the features here on the table, right in front of me. That’s brilliant!”
So in summary, there is something brilliant, even magical about index cards. The power of such a simple technique has taken me completely by surprise, and I’ll certainly be doing more if it in the future. Give it a go yourself, and let me know how you get on. Your stakeholders will love you for it, I promise!