Eine User Story ist eine aus Anwendersicht umgangssprachlich und umsetzungsneutral formulierte Anforderung an eine Software.

Wesentliches Merkmal von User Storys ist, dass sie in natürlicher Sprache verfasst sind und eine Interaktion des Anwenders mit der Software beschreiben. Sie sind deshalb keine technische Spezifikation, sondern beschreiben eine Erwartungshaltung des Anwenders.

Story Cards werden zu User Storys

Als Ursprung des User-Story-Konzepts gilt Extreme Programming, das Kent Beck ab 1996 bei einem Projekt für Chrysler erstmalig in Form von "Story Cards" einsetzte (Wikipedia: Extreme Programming, 2018). Im Rahmen dieses Projekts prägte Alistair Cockburn den Ausspruch: "A story card is a promise for conversation" (Cockburn, Alistair: Origin of story card is a promise for a conversation, 2017). Daraus entwickelte sich der "CCC"-Dreischritt für die Behandlung von User Storys: Card, Conversation, Confirmation (Jeffries, Ron: Essential XP: Card, Conversation, Confirmation, 2001).

Use Case und User Story

User Storys stellen eine intuitivere Formulierung von Use Cases dar. Ivar Jacobsen bezeichnet sie deshalb auch als "Use-Case Narratives" (Jacobsen, Ivar; Spence, Ian; Bittner, Kurt: Use Case 2.0. The Guide to Succeeding with Use Cases, 2011). Während Use Cases normalerweise streng formalisiert in UML notiert werden, so dass sie nur noch für Experten verständlich sind, können User Storys auch von Anwendern verstanden und z.T. sogar selbst formuliert werden.

Das Role-Feature-Reason- oder Connextra-Template

Aufgrund der weiten Verbreitung tragen viele Anwender zur Weiterentwicklung des User-Story-Konzepts bei. So gibt es insbesondere eine Reihe von Schemata, die das Formulieren von User Storys vereinheitlichen und erleichtern sollen. Das bekannteste und am weitesten verbreitete Schema ist das in den 1990er Jahren bei der britischen Software-Entwicklungsfirma Connextra entwickelte Role-Feature-Reason-Schema:

• Als [Rolle / Persona]
• möchte ich [Tätigkeit, Anforderung],
• um [Zweck, Ziel]

Dieses Schema dient zur Unterstützung bei der Formulierung von User Storys, darf jedoch nicht als starres Formular angesehen werden. Gleiches gilt für alle anderen verwendeten Schemata.

Epics und User Storys

Die allgemeine Definition von User Storys erlaubt es, dass sowohl detaillierte (z.B. "Als Online-Besteller möchte ich den Warenkorb abspeichern, um später den Kauf fortzusetzen") als auch sehr allgemeine Anforderungen (z.B.: "Als Endkunde möchte ich meine Waren online kaufen, um Zeit zu sparen") formuliert werden. Für übergreifende User Storys, die in weitere User Storys strukturiert werden, hat sich deshalb zur Unterscheidung die Bezeichnung "Epic" eingebürgert.

INVEST-Kriterien für User Storys

Als Qualitätskriterien für User Storys schlug Bill Wake sechs Aspekte vor, die er im Akronym "INVEST" zusammenfasste (Wake, Bill: INVEST in Good Stories, and SMART Tasks, 2003):

• I: Independent
• N: Negotiable
• V: Valuable
• E: Estimable
• S: Small
• T: Testable

Backlogs und Story Maps

Die Verwendung von User Storys für die Projektplanung und -steuerung kann auf unterschiedliche Weise erfolgen. Sie können sowohl in traditionell als auch agil gemanagten Projekten als Basis für die Erstellung des Leistungsumfangs verwendet werden.

Die einfachste Vorgehensweise besteht darin, die User Storys unstrukturiert im Backlog zu sammeln, nach Priorität zu sortieren und beginnend mit der höchsten Priorität sequentiell abzuarbeiten.

Erweist sich eine einfache Priorisierung als nicht mehr ausreichend, werden User Storys in sog. Story Maps strukturiert. Dort werden die Epics oben horizontal in der Reihenfolge ihres Auftretens angeordnet. Nach unten werden dann mit zunehmender Detailtiefe die zum jeweiligen Epic gehörenden User Storys eingetragen.