User story

From Wikipedia, the free encyclopedia

A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. User stories are used for the specification of requirements (together with acceptance tests) in the software engineering method Extreme Programming (XP). Each story is written on a small paper note card to ensure that it does not grow too large. The stories should be written by the customers for a software project and are their main method of influence on the development.

User stories are a quick way of handling customer requirements without having to deal with large formal requirement documents and tedious tasks related to maintaining them. The intention is to be able to respond faster and with less overhead to rapidly changing real-world requirements.

A user story is an informal statement of the requirement. When a user story is to be implemented, a more formal acceptance test must be written by the customer to ensure that it is later possible to determine whether the goals of the story have been fulfilled.

1 Creating User Stories
2 Example
3 Usage
4 Benefits
5 Limitations
6 References
7 See also
8 External links

[edit] Creating User Stories

When the time has come for creating user stories, one of the developers gets together with a customer representative. The customer is responsible for formulating the user stories. The developer may use a series of questions to get the customer going, such as asking if some particular functionality is desired, but must be careful not to dominate the idea creation process.

As the customer conceives the user stories, they are written down on a note card (e.g. 3x5 inches or 8x13 cm) with a name and a description which the customer has formulated. If the developer and customer find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory. However, it is stressed in XP that user stories are not to be definite once they have been written down. Requirements tend to change during the development period, which is handled by not carving them in stone.

[edit] Example

Starting Application
The application begins by bringing up the last document the user was working with.

Closing Document
If user closes the application, they are prompted to save.

[edit] Usage

As a central part of the planning game, user stories define what is to be built in the software project. User stories are prioritized by the customer to indicate which are most important for the system and will be broken down in tasks and estimated by the developers.

When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. The short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written.

Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to verify it. Without a precise formulation of the requirements, unconstructive prolonged arguments may arise when the product is to be delivered.

[edit] Benefits

XP favours face-to-face communication over comprehensive documentation and quick adaptation to change instead of fixation of the problem. User stories achieve this by:

Being very short
Allowing developer and client to discuss requirements throughout the project lifetime
Needing very little maintenance
Only being considered at the time of use
Maintaining a close customer contact

[edit] Limitations

Some of the limitations of user stories in XP:

Without accompanying acceptance tests, they are open to interpretation which makes them difficult to use as the basis for agreement
They require close customer contact throughout the project which in some cases may be difficult or may be an unnecessary overhead