Stories


 * User Stories **toc

Background
[|A user story] is a short description of a required functionality from a user's perspective. A user story includes a sentence or two and more importantly a series of conversations about the desired functionality (Cohn, 2004).They are written on note cards which can be annotated with estimates made by developers. Customers can then elaborate more about the contents of the story cards to developers if necessary. An acceptance criteria is written on the back of the story card and customer acceptance indicates that developers have produced what is required of them. Stories should be estimated at between one to five programming weeks and they should be testable (Beck, 2000). A user story is not a requirement statement but it provides a high level overview of requirements for a system.

Definition
A user story is defined as a unit of customer-visible functionality that can be implemented in a single iteration (Beck, 2000). A user story includes a priority level, an estimate of the time required to complete the task and sometimes, who will be responsible for the completion of the task. Epics are large user stories which contain multiple short stories that can be hard to plan and estimate. They do not go well with short iterations. Themes are series of related user stories.

The Critical Aspects of User Stories
The 3 critical aspects of user stories are defined as follows: (Jeffries, 2001)

Card
This is the index card used for planning and prioritisation. The card serves as an identification and reminder of requirements. It is exchanged between the customer and developer during an iteration.

Conversation
A conversation refers to the communication of the requirement from the customer to the developer. The conversation is usually not a single one but an on-going conversation throughout the project timeline.

Confirmation
A confirmation refers to the Acceptance Tests. It is usually written at the back of the index card. A confirmation gives high-level criteria against which the user will test the resulting features and confirm that the story is completed.

Features of a Good User Story
A good user story is characterised by the following abbreviations known as [|INVEST] (Wake, 2003)

**Independent** User stories should be independent of each other as interdependencies can lead to prioritisation issues. **Negotiable**There should be flexibility and room for adjustment prior to implementation**Valuable**User stories must be valuable both by the customer and developer.**Estimable**A story should be addressed by knowledgeable developers who can give an estimate of the duration for completion.**Small**User stories should be small to make for easy estimation and planning. User stories should be testable to demonstrate that they meet the expectation(s) of the customer.
 * Testable**

Advantages (Cohn, 2004)

 * **User stories emphasizes verbal communications**
 * Written language is often not precise and so the conversation between the customer and developer helps to clarify what is required. When a user writes a statement that is not clear to the developer, that developer questions the statement and gets immediate clarification while interacting with the customer.
 * **User stories are useful for project planning**
 * User stories are written so that developers can give a rough estimate of how easy or time consuming it will take to develop the product.
 * A good level story can be written and later replaced with more detailed stories when it is important to have the details.This makes user stories perfect for time constrained project. A few stories can be written to get the developer started on the coding immediately and then later ask for the other details.

Limitations of User Stories

 * User stories might be difficult to work with in the case of large projects.
 * User stories do not always interpret requirements as best as is needed and customers and developers might have to exchange a few conversations before the requirements are properly understood.

External Link
Wake. B (2003) [] [Accessed: 14 March, 2012] Cohn, M (2004) [] [Accessed: 14 March, 2012]