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

Storywriters come from a Project Community that includes

Customer Representatives/Customer(s)
Subject Matter Experts (SME)
Domain Experts
Business Experts
Gold Owners

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.

Testable

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.

Estimatable

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.

Guidelines

Here are some quick guidelines to follow when attempting storytelling, in the order of importance:

Ensure that customers of the system or their representatives are the ones who write the stories.
The title should follow the 5-word rule. If you cannot express the story in 5 words or less, then examine if the story should be broken down further, or if all the writers of the story truly understand what the story is doing.
Use active verbs in the title.
Check that your story is testable.
Be prepared to clarify or revise the stories during the Planning Game based on negotiation and discussion with developers.