Den meisten dürfte der Begriff „User Story“ im Zusammenhang mit Agiler Softwareentwicklung bekannt sein, z. B. in Verbindung mit Scrum und agilen Anforderungen. User Stories als reine Dokumentationsform zu bezeichnen, schriftliche Anforderungen, die eben im agilen Umfeld vorkommen, greift allerdings ein Stück zu kurz.Ursprünglich sind User Stories eine Technik aus dem Extreme Programming. Sie stellen mentale Anker dafür da, dass der Kunde ein bestimmtes Feature möchte, und dass über die Details der Umsetzung dieses Features noch diskutiert werden muss. Mike Cohn nennt sie „Kommunikationsversprechen“ (tokens for promising future communication): Sie dienen als Grundlage für Kommunikation, die zu einer Einigung führt, mit der Entwicklungsteam und Kunde einverstanden sind.User Stories können prinzipiell beliebig aufgebaut sein. Zum Beispiel ist „Studenten können ihre Parktickets online kaufen“ genauso eine User Story wie „Als Mitarbeiter möchte ich meine Stunden nach Kategorien eingeben können, damit meine Aufwände transparent werden“. In der Praxis hat sich, unter anderem durch Mike Cohns „User Stories“ [1] und durch die zunehmende Normierung durch zahlreiche Trainingsangebote und Zertifizierungsmöglichkeiten, eine Standardform herausgebildet:

Als <Rollenbezeichnung/Persona>

möchte ich <Funktionalität/Systemverhalten>,

so dass <fachlicher Wert für den Benutzer/ wirtschaftlicher Nutzen>.

Dabei steht <Rollenbezeichnung/Persona> für eine bestimmte Gruppe von Benutzern, für die eine Funktionalität gefordert wird. Auf diese Weise können z. B. Rollenkonzepte in User Stories integriert oder zielgruppenspezifische Aspekte berücksichtigt werden, anstatt nur vom Standardanwender auszugehen.

<Funktionalität/Systemverhalten> enthält den Kern der Anforderung, also eine Beschreibung der Funktionalität, die das System bereitstellen soll, oder die Beschreibung einer Eigenschaft, die das System besitzen soll. Die Funktionalität oder Eigenschaft wird nicht bis ins letzte Detail beschrieben – schließlich handelt es sich nicht um eine Anforderung, die einfach über den Zaun geworfen wird, sondern um die Grundlage für ein Gespräch.

Der optionale dritte Teil einer User Story, die Beschreibung des fachlichen Werts bzw. wirtschaftlichen Nutzens, dient dazu, eine Motivation und eine Grundlage für die Priorisierung der geforderten Funktionalität zu liefern. Die Motivation, also die zugrundeliegende Intention der Forderung, kann auch Hinweise zu weiteren Aspekten liefern, die für ein Feature wichtig sind oder die zusätzlich zum beschriebenen Feature für die zukünftigen Benutzer interessant sein könnten.

Im zweiten Teil der Blogserie zur unterstützenden Technik „User Stories“ lesen Sie, wie sich die Qualität von User Stories bewerten lässt.

Quellen: [1] Cohn, Mike: User Stories für die agile Entwicklung mit Scrum, XP. mitp-Verlag, 2010