What is a user story?
A 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 story describes some functionality and is both meaningful to the customer and to the team. A story comprises the following elements:
- Card: A written description of the functionality used for adaptively planning incremental development.
- Conversation: Discussions facilitating a drill-down into the details of the functionality required.
- Confirmation: Acceptance tests capturing the details and used to determine when a story is complete.
While the card contains the description of a story, the details are derived through conversation and recorded in the confirmation. Think of stories as representing a conversation that has occurred between the customer and the team as opposed to documenting customer requirements.
How long should a user story take to develop and test?
A story should take about between two days and two weeks to complete.
Capturing the details
It’s difficult to start developing a story without more detail. The developers should discuss the details of a story with the customer at the point when the details become important, adding notes to the story card as appropriate. What is important here is the conversation between the customer and the team, and not the annotated story card. Stories are not contractual obligations. Agreements between the customer and the team are documented by acceptance tests, which demonstrate that a story has been developed correctly. In some situations it may make more sense to include details as new stories. It’s better to have more stories than to have a few stories representing greater functionality. Stories that are too large are called epics and the customer should split them into two or more smaller stories.
Acceptance tests
The expectations of the customer are recorded as acceptance tests. The test descriptions convey additional information about the story, which helps the team to recognize 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 team early.
Who writes the stories and acceptance tests?
The customer writes the stories and acceptance tests for the following reasons:
- The customer is in the best position to describe the desired functionality.
- Each story must be written in the language of the business so that the customer can prioritize the stories by business value and select the 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.
