AGILE IN ACTION: But that's another story

Monday, May 30, 2005

But that's another story

What is a user story?

A user story is a distinct unit of customer-visible functionality that does not have to represent business value but must represent progress to the customer. A user story describes some functionality and is both meaningful to the customer and to the developers. A user story comprises the following elements:

1. Card: A written description of the functionality used for adaptively planning incremental development
2. Conversation: Discussions facilitating a drill-down into the details of the functionality required
3. Confirmation: Acceptance tests capturing the details and used to determine when a user story is complete

While the card contains the description of a user story, the details are derived through conversation and recorded in the confirmation. Think of user stories as representing a conversation that has occurred between the customer and the developers, as opposed to documenting customer requirements.

How long should a user story take to develop and test?

A user story should take about between two days and two weeks to complete.

Capturing the details

It's difficult to start developing a user story without more detail. The developers should discuss the details of a user story with the customer at the point when the details become important, adding notes to the user story as appropriate. What is important here is the conversation between the customer and developers, and not the annotated user story. User stories are not contractual obligations. Agreements between the customer and developers are documented by acceptance tests, which demonstrate that a user story has been developed correctly. In some situations it may make more sense to include details as new user stories. It's better to have more user stories than to have a few user stories representing greater functionality. User stories that are too large are called epics and the customer should split them into two or more smaller user stories.

Acceptance tests

The expectations of the customer are recorded as acceptance tests. The test descriptions convey additional information about the user story, which helps developers to recognise when they are done. Acceptance tests should be written as early as possible so that the customer's assumptions and expectations are communicated to the developers early.

Who writes the user stories and acceptance tests?

The customer writes the user stories and acceptance tests for the following reasons:

1. The customer is in the best position to describe the desired functionality
2. Each story must be written in the language of the business so that the customer can prioritise the user stories by business value and select the user stories for each sprint.

The developers and testers can assist the customer but the responsibility for writing stories must reside with the customer. If testers are present, they should be responsible for developing automated acceptance tests, otherwise developers should do it.

Compulsory reading

Mike Cohn's book User Stories Applied For Agile Software Development

Tags: agile, user stories