User story

A user story is a software system requirement formulated as one ortwo sentences in the everyday language of the user. User stories are used under the "Extreme Programming" (XP) paradigm forthe specification of requirements (together with acceptance tests)(XP). Each "user story" is limited, so it fits on a small paper note card — usually a 3×5 inches card — to ensure that it does not grow toolarge. The "user stories" should be written by the customers for a softwareproject and are their main instrument to influence the development of the software.

"User stories" are a quick way of handling customer requirements withouthaving to elaborate vast formalized requirement documents and without performing overloaded administrative tasksrelated to maintaining them. The intention with the "user story" is to be able to respond fasterand with less overhead to rapidly changing real-world requirements.

A "user story" is an informal statement of the requirement as long as the correspondence of "acceptance testing procedures" is lacking. Before a "user story" is to be implemented, an appropriate "acceptance procedure" must be written by the customer to ensure by testing or otherwise determine whether the goals of the "user story" have been fulfilled. Some formalization finally happens when the developer accepts the "user story" and the "acceptance procedure" as his work specific order.

Creating user stories

When the time has come for creating user stories, one of the developers getstogether with a customer representative. The customer is responsible forformulating the user stories. The developer may use a series of questionsto get the customer going, such as asking if some particular functionalityis 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 notecard (e.g. 3x5 inches or 8x13 cm) with a name and a description which thecustomer has formulated. If the developer and customer find that the userstory is lacking in some way (too large, complicated, imprecise), it isrewritten until it is satisfactory. However, it is stressed in XP that userstories are not to be definite once they have been written down.Requirements tend to change during the development period, which is handledby not carving them in stone.

Example

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

Closing Application Upon closing the application, the user is prompted to save (when ANYTHING has changed in data since the last save!).

Usage

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

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

Every user story must at some point have one or more acceptance testsattached, allowing the developer to test when the user story is done andalso allowing the customer to verify it. Without a precise formulation ofthe requirements, unconstructive prolonged arguments may arise when theproduct is to be delivered.

Benefits

XP favours face-to-face communication over comprehensive documentation andquick adaptation to change instead of fixation of the problem. User storiesachieve this by:

* Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
* 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
* Allow projects to be broken into small increments
* Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
* May be easier to estimate development effort

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 unnecessary overhead
* Can have difficulty scaling to large projects.
* Rely more on competent developers
* User stories are regarded as conversation starters. Unfortunately they may not capture where the conversation ended and fail to serve as a form of reliable documentation of the system.

References

* Daniel H. Steinberg and Daniel W. Palmer: "Extreme Software Engineering", Pearson Education, Inc., ISBN 0-13-047381-2
* Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5
* Mike Cohn: "Agile Estimating and Planning", 2006, Prentice Hall, ISBN 0-13-147941-5

See also

* Acceptance test
* Extreme Programming
* Requirement
* Scrum (development)
* Use Case

External links

* [http://www.extremeprogramming.org/rules/userstories.html Definition of User Stories at extremeprogramming.org]
* [http://c2.com/cgi/wiki?UserStory Definition of User Story at c2.com]