Indexing Project Borat
May 5, 2006
Have I mentioned I love 3×5 index cards? They are quite possibly one of the finest inventions ever, for several reasons:
The first three are obvious, but the last one is the lynchpin. Small is good because it enforces a reasonable constraint on the amount of information it contains. Small is good because you can fit a whole bunch on a desk, and you can move them around easily. Small is good because it’s “less,” and as the fine folks at 37 Signals like to say … Less is more.
What does this have to do with Project Borat? Well, index cards are really terrifically superbly great for collecting user stories. They’re not nearly as intimidating as filling out an official looking forms, and the interface is a heck of a lot more intuitive than any project management software I’ve ever seen. They encourage ideas, and when it comes time to cull the herd, they’re satisfying to rip up and chuck in the recycle bin.
The process of generating user stories with index cards is about as simple as it gets:
- Write down a goal on the front of the card. Something like “Person signs up for the site.”
- On the back of the card, jot down some notes about the process. “Requires opt-in confirmation of e-mail address, unique username”
- Cluster cards in some logically satisfying manner on the table. I suggest by functionality. For example, “User invites a friend to join the site” and “User removes a friend from friends list” both seem to fit into friend management.
When you think you have good coverage, take each cluster of cards and rubber band them together. If you have a lot of stacks and a lot of cards, feel free to put a top card on the stack to identify the general functionality.
In the case of Project Borat, it took about 1.5 hours to generate ~65 use cases in 12 groups. This isn’t complete coverage, it’s just for the business specific features of the site. Other things (like administrative user management) aren’t as sexy, and are relatively straight forward to implement without much guidance.
If you read my last installment, you’re probably thinking “where does the butcher paper fit into this?” It hasn’t, but it will—I just thought it would be good to break things down a bit more. The next step is selecting a core set of use cases that really define what the application is about … and then we hit the butcher paper.