User story

from Wikipedia, the free encyclopedia

A user story (“user narration”) is a software requirement formulated in everyday language . It is deliberately kept short and usually does not contain more than two sentences.

User stories are used in the context of agile software development (e.g. Extreme Programming (XP), Scrum ) together with acceptance tests to specify requirements . Each user story is written on a story card. The author of the story should be the customer of the software project.

Create user stories

User stories can either be created informally or using a template:

"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>"

Examples

The following example uses the template "As <role> I would like <target / wish> to <benefit>":

Start application:

As an author, I want to see my last edited document after starting the application to save time.

The two following examples show the structure of a heading and a single sentence in free form. In the first example it is not clear who the actor is. In the second it is not clear what "quit" is exactly.

Start application:

The application starts by opening the last edited document by the user, so that the user saves time.

Close application:

When the user exits the application, a query appears asking whether the edited document should be saved so that changes are not lost.

Story decomposition

Story Decomposition ensures that the user stories are described with an adequate level of detail and that the user stories are derived from the user goals. It works from breadth to depth in order to gradually refine the requirements: The starting point is the user goals to be achieved; therefrom are Epics derived which are broken down into user stories; the user stories are supplemented by acceptance criteria.

Story card

Example of a template for the front of story cards
Example of a template for the backs of story cards

The medium on which a user story is documented is described as a story card, usually pieces of paper (e.g. sticky notes ) or computer data records .

The story cards serve in particular as a means of communication between requesters and implementers. The story card contains the description of the story, usually in the form of a sentence based on the template described above. Furthermore, the result of an estimate can be recorded directly on the story card, usually in the form of story points.

Traditionally, the back of the story card contains the description of the acceptance criteria for the user story. However, if the back is not accessible and / or several acceptance criteria have to be defined for a user story, these can also be recorded on separate slips of paper or in a computer system.

With the acceptance criteria, the requester describes how he would test the correct implementation of the user story. This is helpful both for understanding and for testing the user story. In the event of changes, the behavior to be changed should also be documented.

When using Behavior Driven Development , these acceptance criteria are written in the form of sentences with a defined structure. In particular, the Gherkin syntax is used here to enable automatic testability. The description of the story on the story card serves as a conceptual link between the story card and the associated acceptance criteria. Since the acceptance criteria must be clear, precise and (at least in principle) automatically testable, they can be very extensive.

User story map

Simple story map display

A user story map shows user stories in a graphical overview. The successive activities of the user are shown horizontally with a user story. Vertical is detailed from top to bottom: e.g. B. starting with the customer goals over epics up to the user stories. A user story map provides an overview of all user stories.

Differentiation between user story and use case

The use cases in classic software development without agile methods are similar to user stories in that they represent requirements in the language of the user and in context.

In a use case , however, all success and failure scenarios for the possible achievement of a professionally relevant goal are presented in a bundle. A user story, on the other hand, represents a professionally motivated requirement that a user can assess as successfully or not successfully implemented, but the user will not be able to achieve a professional goal with the user story alone.

A use case can thus form the context for many user stories : A user story is the heading of a specific scenario, a use case contains several of these scenarios.

literature

  • Mike Cohn: User Stories: for agile software development with Scrum, XP and others mitp, Bonn 2010, ISBN 978-3-8266-5898-3 .
  • Daniel H. Steinberg, Daniel W. Palmer: Extreme Software Engineering. A hands-on approach . Pearson Prentice Hall, Upper Saddle River, New Jersey 2004, ISBN 978-0-13-047381-3 .
  • Ralf Wirdemann: Scrum with user stories . 2nd Edition. Hanser, Munich 2011, ISBN 978-3-446-42660-3 .

Web links

Individual evidence

  1. ^ Scott W. Ambler: Introduction to User Stories. Initial User Stories (Formal). In: Agile Modeling. Retrieved March 20, 2014 .
  2. Fa. Ibo: Agile Business Analysis: everything to do with user stories. Retrieved on March 20, 2014 (German).
  3. Fa. Ibo: Agile Business Analysis: everything to do with user stories. Retrieved on March 20, 2014 (German).
  4. Alistair Cockburn: Creating Use Cases effectively. mitp, Bonn 2003, ISBN 3-8266-1344-9 , p. 231.
  5. Jens Coldeweys: Methodology: Use Cases, User Stories and Acceptance Tests. Retrieved on March 20, 2014 (German).