Extreme Programming has this strong tradition of using index cards to track user stories, or to aid in design through the use of CRC cards.
Now, I have always had a strong preference for Excel spreadsheets. You can print them, e-mail them, share them, and save them.
But there is something wonderful in the very nature of index cards. Their very constraints create interesting feedback loops. Think of all the objections that you might have against them:
Index cards are too easy to lose.
Yes – but why are you writing anything important on an index card in the first place? At the end of the day, the only important work product is the code. Requirements and any other models exist to facilitate conversations about the code. If you have been writing tests along the way, when the coding is done, the requirements don’t need to exist anymore. The requirements aren’t sacred. The only thing that is sacred, the desires of your users, cannot be captured in any format, but must be discovered through a constant dialog.
Index cards are too bulky.
If you have more index cares than you can manage, then your user stories are either too fine grained or your scope is too ambitious. Either way, the cards are telling you that you need to change.
This is a pet peeve of mine. Quite often, when you are doing the wrong thing, it will be difficult. The correct solution is not to make it easier to do the wrong thing, but to change what you were doing in the first place.
Only one person can “own” an index card at a time.
So what? Distributed ownership is the worst thing that can happen in project management. If everyone owns a task, then no one is really responsible for carrying it out.
Having said all that, I am still mulling over the use of index cards in my process, and have started collecting links about index cards in del.icio.us.
