|Industrial XP Storytelling|
Use index cards to describe the features of the system to be built
Customers tell stories about the system they want built. A story represents some functionality of the system. Stories provide a context for communication between the customer and the developer. They are not only revised during storytelling, they are also updated during the course of the project as and when more information becomes available.
Alistair Cockburn says “A story is a promissory note for a conversation.” Stories should be lightweight, with the details coming out through conversations between customers and developers. A story is recorded on an index card, with details on a sticky note.
You can only write so much detail as will fit onto the surface of the sticky note. If a story seems to need too much detail, then the story is really asking to be split up into smaller stories.
The 5-word Rule
We like to enforce the 5-word rule when writing stories. If your title contains more than 5 words, then it probably needs refactoring. Review your story. Is it clear enough? Do the authors of the story understand it well enough?
At the end of a storytelling session, it is a good exercise to pick out stories that violate this rule, and re-examine them. People who write such stories often do not understand them well, and need to clarify or simplify it through further discussions.
Active Verb Rule
When writing the title of a story, it is important to use active verbs. Verbs communicate action, and action sticks in people's minds. Passive speech is boring, and does not inspire as much thought and discussion. “Compute Billing Info” is better than “Billing Info Computation”.
Storywriters come from a Project Community that includes
Storywriters have a deep knowledge of the business rules that will reside in the system to be built. They are the people who would usually write requirements documents for the system.
Stories should lend themselves well to automated testing. A story that is too hard to test needs rewriting. The stories to storytests ratio is not always 1:1. A story may have multiple storytests covering it. It is also possible to have one storytest covering multiple stories.
Complex or vague stories are hard to estimate. During the Planning Game, such stories are uncovered, and storywriters end up breaking them into smaller estimatable pieces or dropping some details based on business priorities.
Here are some quick guidelines to follow when attempting storytelling, in the order of importance:
Further ReadingUser Stories Applied: For Agile Software Development by Mike Cohn.