User Story

Grundidee und Zweck

Eine User Story („Anwendererzählung“) ist eine bewusst kurze, in Alltagssprache formulierte Software-Anforderung. Sie umfasst in der Regel höchstens zwei Sätze. In der agilen Softwareentwicklung, etwa bei Extreme Programming (XP) oder Scrum, dienen User Stories zusammen mit Akzeptanztests dazu, Anforderungen zu spezifizieren. Jede User Story wird auf einer Story-Card dokumentiert. Der Autor sollte der Kunde des Softwareprojekts sein.

User Stories beschreiben eine fachlich begründete Anforderung aus Sicht eines Anwenders. Ihre knappe und verständliche Form unterstützt die Kommunikation zwischen den Personen, die eine Anforderung stellen, und den Personen, die sie umsetzen.

Form und Beispiele

Eine User Story kann frei formuliert oder nach folgender Vorlage erstellt werden: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“. Die drei Bestandteile benennen, wer etwas benötigt, was erreicht werden soll und welchen Nutzen dies hat.

Ein Beispiel lautet: „Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.“ Hier sind Rolle, Ziel und Nutzen eindeutig erkennbar.

Auch eine freie Form aus Überschrift und einem Satz ist möglich, kann aber unklarer sein. Beim Satz „Die Anwendung startet, indem sie das zuletzt bearbeitete Dokument des Anwenders öffnet, damit der Anwender Zeit spart“ bleibt beispielsweise offen, wer der Autor der Anforderung ist. Beim Beispiel zum Schließen einer Anwendung soll eine Anfrage erscheinen, ob das bearbeitete Dokument gespeichert werden soll, damit Änderungen nicht verloren gehen. Dabei ist jedoch nicht eindeutig, was „beenden“ genau bedeutet.

Schrittweise Zerlegung

Die Story Decomposition sorgt dafür, dass User Stories einen angemessenen Detaillierungsgrad besitzen und aus den Zielen der Anwender abgeleitet werden. Die Anforderungen werden dabei schrittweise von der Breite in die Tiefe verfeinert.

Ausgangspunkt sind die zu erreichenden Anwenderziele. Daraus werden Epics abgeleitet. Ein Epic ist eine größere, noch grob beschriebene Anforderung. Die Epics werden anschließend in einzelne User Stories zerlegt. Zu diesen User Stories werden schließlich Akzeptanzkriterien ergänzt, die festlegen, woran eine korrekte Umsetzung erkannt werden kann.

Dokumentation und Akzeptanzkriterien

Eine Story-Card ist das Medium, auf dem eine User Story dokumentiert wird. Das kann ein Zettel, etwa ein Klebezettel, oder ein Computerdatensatz sein. Story-Cards dienen vor allem als Kommunikationsmittel zwischen Anforderern und Umsetzern.

Auf der Story-Card steht die Beschreibung der Anforderung, üblicherweise als ein Satz nach der Rollen-Ziel-Nutzen-Vorlage. Zusätzlich kann dort der geschätzte Realisierungsaufwand festgehalten werden. Als relative Maßeinheit wird dafür häufig der Story-Point verwendet; für ihn existieren verschiedene Definitionen und Berechnungsverfahren.

Traditionell stehen die Akzeptanzkriterien auf der Rückseite der Story-Card. Ist diese nicht zugänglich oder gibt es mehrere Kriterien, können sie auf getrennten Zetteln oder in einem Computersystem erfasst werden. Mit Akzeptanzkriterien beschreibt der Anforderer, wie er die korrekte Umsetzung testen würde. Sie helfen damit sowohl beim Verständnis als auch beim Testen der User Story. Bei einer Änderung sollte zusätzlich das zu ändernde Verhalten dokumentiert werden.

Beim Behavior Driven Development werden Akzeptanzkriterien als Sätze mit einer festgelegten Struktur verfasst. Besonders die Gherkin-Syntax soll eine automatische Testbarkeit ermöglichen. Die Beschreibung der User Story bildet dabei die konzeptionelle Verbindung zu den zugehörigen Akzeptanzkriterien. Da diese Kriterien klar, präzise und zumindest grundsätzlich automatisch testbar sein müssen, können sie deutlich umfangreicher als die eigentliche User Story ausfallen.

Grafische Übersicht

Eine User Story Map stellt User Stories grafisch dar und schafft einen Überblick über alle vorhandenen Anforderungen. Auf der horizontalen Achse stehen die aufeinanderfolgenden Aktivitäten des Anwenders, jeweils dargestellt durch eine User Story. Vertikal nimmt der Detaillierungsgrad von oben nach unten zu: Die Darstellung kann beispielsweise bei den Kundenzielen beginnen, über Epics führen und schließlich die einzelnen User Stories zeigen.

Unterschied zum Use Case

Use Cases der klassischen Softwareentwicklung ohne agile Methoden ähneln User Stories, weil auch sie Anforderungen in der Sprache des Anwenders und in ihrem Kontext darstellen. Der Umfang und die Funktion unterscheiden sich jedoch.

Ein Use Case bündelt alle Erfolgs- und Misserfolgsszenarien, die bei der möglichen Erreichung eines fachlich relevanten Ziels auftreten können. Eine User Story beschreibt dagegen eine einzelne fachlich motivierte Anforderung. Ein Anwender kann beurteilen, ob sie erfolgreich umgesetzt wurde, erreicht aber allein mit dieser einen User Story normalerweise noch kein vollständiges fachliches Ziel.

Ein Use Case kann deshalb den Kontext für viele User Stories bilden. Vereinfacht ausgedrückt ist eine User Story die Überschrift eines konkreten Szenarios, während ein Use Case mehrere solcher Szenarien umfasst.