User story


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]


Wikimedia Foundation. 2010.

Look at other dictionaries:

  • User Story — Eine User Story („Anwendererzählung“) ist eine in Alltagssprache formulierte Software Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden im Rahmen der Agilen Softwareentwicklung (z.B …   Deutsch Wikipedia

  • User-Story — Eine User Story („Benutzergeschichte“) ist eine in Alltagssprache formulierte Software Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden in Extreme Programming (XP) zusammen mit… …   Deutsch Wikipedia

  • Story-Card — Story Cards sind Hilfsmittel im Rahmen des Anforderungsmanagements, die es dem Kunden ermöglichen, das erwünschte Verhalten eines zu erstellenden Systems durch prosaische Kurzbeschreibungen zu spezifizieren. Hierbei wird es ihm ermöglicht, in… …   Deutsch Wikipedia

  • Story — NOTOC Story can mean:Description of a sequence of events* For the description of a sequence of events, commonly called a story, see narrative ** Short story or a novella ** Bedtime story, an entertaining or instructive, soporific, and often… …   Wikipedia

  • User Account Control — (UAC) is a technology and security infrastructure introduced with Microsoft s Windows Vista operating system. It aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator …   Wikipedia

  • User Friendly (disambiguation) — User Friendly is an online comic strip featuring technology related storylines.User Friendly may also refer to:* User Friendliness, a concept in software engineering.In literature* User Friendly , a collection of stories by Spider Robinson,… …   Wikipedia

  • User-generated TV — User Generated Television or UGTV refers to TV footage that was originally created by a member of the public and then uploaded to the internet. Often the process of selecting such footage for broadcast includes the input of web users. UGTV can… …   Wikipedia

  • User Interface Privilege Isolation — (UIPI) is a technology introduced in Windows Vista and Windows Server 2008 to combat code injection exploits. By leveraging Mandatory Integrity Control, it prevents processes with a lower integrity level (IL) from sending messages to higher IL… …   Wikipedia

  • User Interface Privilege Isolation — (UIPI Isolation des privilèges de l IHM) est une technique de sécurité utilisée par Windows Vista et Windows Server 2008 pour se protéger contre les exploits d injection de code. UIPI évite qu un processus ayant un bas niveau de sécurité… …   Wikipédia en Français

  • Story points — are units of relative size used in estimating tasks in agile software development. UsageTypically when a list of tasks to be done is created (in agile development usually called a backlog and consisting of user stories) the team estimates the… …   Wikipedia