A document is both a communication medium and a storage mechanism. Although a conversation provides us with a rich communication medium, the words may be lost in the ether with no record except in the memories of the participants. During team planning workshops, XP teams use index cards to make notes about stories being discussed. There is no formal form for a story card; it can be written in any way that is useful (although a short name for the story as a heading helps). These cards are used after the weekly planning session to create a visible plan on the wall. Each day the team holds a meeting around the plan to review the work remaining for the week. It’s possible that a few days may elapse before I start work implementing a story but because the team sit together I can replay the conversation with them before I start work.
Agile software development is not a series of mini-waterfalls. The notes on index cards are not the counterparts of requirements documents; this is a different process model. There are several tools available for managing electronic story cards – that seem to miss the point that the story card description is not a requirements document in the traditional sense and treat these as the prime artefact rather than the story tests. Index cards provide a non-intrusive way of documenting a conversation without disrupting the flow. The cards are not a simple input from which a conversation is generated; they are also an output of the conversation. A story card is not a stand-alone document describing the full requirement it is really a brief note that a token that to remind us of key details from a conversation. Our primary source of information during the development is conversation, made possible by co-locating the team.
The return to handwriting on cards appears to be a retrograde step. Surely, people in the software industry should be using the latest software tools for planning? To understand why index cards are preferred for planning with stories, you need to understand that paper has different "affordances" – interactions that it supports – and limitations. For example, spatial layout – it is easy to shuffle tasks written on index cards around to create different layouts. When planning it helps to review prioritization from different perspectives – by risk, by value, etc. Another affordance is visibility - it is easier for a group of people to read index cards spread out on a table than gather around a computer screen. Index cards can be annotated by grabbing a pen. Grabbing the keyboard in a meeting usually means changing seats. I have worked with teams who have used data projectors in meetings to make the computer screen visible to all but what happens is the group end up waiting for the operator to keep up with them. The way we interact with today’s planning software slows down the meeting dynamics. If we are to use software tools then we need to review how they support group interaction and to remember, rrecording the conversations is a secondary activity, we don’t want it to disrupt the primary activity understanding the desires around the system.
Index cards have some limitations too. If your meeting group is large then some may not be able to read the text on the card. I encourage teams to "write big" using marker pens and move to using sticky-notes on a wall rather than a table if members of the team have problems.
It’s worth remembering that the drive for a "paperless" office  was motivated by the drive to reduce storage costs of large quantities of data - to remove paper records in filing cabinets. Index cards don’t hold a lot of data and can be easily bundled with a rubber band. The notes on the index card are a temporary holder of the requirement. The cards are only used for the purpose of planning; the cards are not intended to become a lasting record. Index cards can be thrown away after they have been translated into acceptance test scripts and committed to version control.