AGILE IN ACTION

What’s a user story?

A user story is a distinct unit of customer-visible functionality, which does not have to represent value to the business but must represent progress to the customer. It’s meaningful to both the customer and the developers. Ron Jeffries uses 3 Cs to describe a user story:

1. Card: The name of the user story (no more than a word or two) used to facilitate collaboration between the customer and the developers.

2. Conversation: Collaboration and discussions that drill-down into the details of the desired functionality.

3. Confirmation: Acceptance tests capturing the details and used to determine when a user story is complete.

Think of user stories as representing a collaboration between the customer and the developers, as opposed to documenting customer requirements. The purpose of this collaboration is to reveal and understand the details of the user stories, which are recorded in the confirmation. Some people write a short description of the user story on the index card, while others like a statement of the format: [Role] can [capability], so that [benefit] . I prefer Rachel Davies’ suggestion, and put just the name of the user story on the index card. A verbose story card encourages people to think of them as requirements documents. A simple name, written in large capital letters, encourages collaboration that continues throughout the iteration

William Wake advises us to INVEST in good user stories :

1. I ndependent: Dependencies between user stories should be avoided because they can lead to prioritisation and planning difficulties.

2. N egotiable: User stories are reminders to collaborate. Collaboration between the customer and the developers involves a negotiation to balance the desired functionality with the cost of implementing it.

3. V aluable to the customer: Whether a user story represents value to the business or simply conveys progress it must inherently be valuable to the customer. This enables the customer to intelligently prioritise user stories. Avoid user stories that have only technical value.

4. E stimatable: There are three reasons why user stories may not be estimatable:

• Developers lack domain knowledge. In this situation, collaborating with the customer will help them understand a user story.
• Developers do not possess the right technical knowledge. They should split the user story into a spike to gather information, and a user story to do the real work. A spike is an experiment that allows the developers to learn just enough about the technology to be able to estimate the user story. A spike must be time-boxed. This defines the maximum time that will be spent learning and fixes the estimate for the spike.
• A user story is too big. It should be split into smaller user stories during collaboration between the customer and developers. When development starts on a user story, it should take between one and two days to complete (including acceptance tests).

5. S mall: If user stories are too big they are difficult to estimate and cannot be planned into a single iteration.

6. T estable: User stories must be testable. A user story that passes all its acceptance tests (and all its unit tests) can be considered complete (subject to a final visual approval by the customer). Without this capability, developers will not know when they’re done .


Who writes the user stories?

The customer writes the user stories because she’s in the best position to know the desired functionality. Each user story must be written in the language of the business. This enables the customer to prioritise the user stories according to their value to the business and their cost, and select the user stories for each iteration. The developers can assist the customer but the responsibility for writing stories must reside with the customer.


Next post in this series:
User stories 2: Adaptive planning

References:
[1] Mike Cohn ’s User Stories Applied For Agile Software Development
[2] Kent Beck ’s Extreme Programming Explained, Second Edition