Was ist eine User Story?

Eine User Story ist eine kurze, in einfacher Sprache verfasste Beschreibung einer Änderung, die aus der Perspektive der Person erzählt wird, die davon profitiert: „Als Stammkunde möchte ich mich mit meiner E-Mail-Adresse anmelden, damit ich meine Bestellhistorie einsehen kann.“ Es handelt sich bewusst nicht um eine Spezifikation. Die Karte enthält das Versprechen, einen Dialog anzustoßen, und die Details ergeben sich erst, wenn das Team die Story verfeinert, ihre Akzeptanzkriterien festlegt und ihren Umfang einschätzt.

Alles andere in diesem Leitfaden basiert auf Stories. Sie sind das, was bei Planning Poker bewertet wird, woran Story-Punkte geknüpft sind und was aufgeteilt wird, wenn sich die Schätzung nicht angleicht. Ein Team, das schlechte Stories verfasst, wird auch schlechte Schätzungen vornehmen, ganz gleich, wie gut es die Sitzung durchführt, denn die Probleme beginnen bereits bei den Eingaben.

Das Format: Rolle, Ziel, Nutzen

Die klassische Form geht auf Connextra, ein Londoner XP-Team, um das Jahr 2001 zurück:

Als [Rolle] möchte ich [Ziel] erreichen, damit [Nutzen] entsteht.

Drei Steckplätze, und jeder erfüllt eine bestimmte Aufgabe.

• Die Rolle gibt an, wer den Wert erhält. „Als Nutzer“ ist der häufigste Fehler in diesem Format: Eine Geschichte, die sich auf jeden beziehen könnte, ist eine Geschichte, bei der sich niemand tatsächlich erkundigt hat. Nennen Sie die konkrete Person – den Stammkunden, den Integrationsentwickler.
• Das Ziel ist die Funktionalität aus Sicht des Benutzers, die beschreibt, was die Person tut, und nicht, wie das System aufgebaut ist. „Ich möchte mein Passwort zurücksetzen“ ist ein Ziel. „Ich möchte einen Microservice zum Zurücksetzen des Passworts“ ist eine Entwurfsentscheidung, die diese Form annimmt.
• Der Nutzen ist der Punkt, den die Teams als Erstes streichen, und er ist der Grund, warum die Karte ihren Platz im Backlog erhält. Das „damit“ ist das Argument der Story für ihre Aufnahme in den Plan. Wenn niemand sie abschließen kann, hat die Arbeit keine Daseinsberechtigung, und durch das Aufschreiben des Satzes finden Sie dies bereits vor Beginn des Sprints heraus – und nicht erst danach.

Karte, Gespräch, Bestätigung

Ron Jeffries hat die Funktionsweise von Geschichten in drei „Cs“ zusammengefasst, wobei die Reihenfolge eine wichtige Rolle spielt.

Die Karte ist ein Symbol – ein oder zwei Sätze, bewusst kurz gehalten. Ihre Größe ist ein wesentliches Merkmal: Sie kann physisch keine vollständige Anforderung enthalten, was dazu führt, dass der nächste Schritt „C“ erfolgen muss.

Im Gespräch wird die Anforderung tatsächlich konkretisiert. Das Team und der Product Owner besprechen die Story im Rahmen der Backlog-Verfeinerung: die Randfälle und alles, was ausdrücklich nicht zum Umfang gehört. Teams, die diesen Schritt überspringen und die Karte als Anforderung betrachten, erleben das Schlimmste aus beiden Welten – ein Dokument, das zu dürftig ist, um darauf aufzubauen, und keinen Dialog, weil „es ja bereits niedergeschrieben ist“.

Die Bestätigung ist das Akzeptanzkriterium: die Bedingungen für „bestanden“ oder „nicht bestanden“, die festlegen, ob das fertige Ergebnis den im Gespräch vereinbarten Anforderungen entspricht. Im Kapitel zur User-Story-Vorlage werden die beiden geeigneten Formate vorgestellt, und im Kapitel zu den Akzeptanzkriterien wird deren Erstellung ausführlich behandelt.

Die INVEST-Checkliste

Bill Wakes Checkliste aus dem Jahr 2003 ist nach wie vor der schnellste Weg, um zu prüfen, ob eine Story bereit für die weitere Bearbeitung ist. Eine gute Story zeichnet sich durch Folgendes aus:

• Unabhängig – kann eigenständig eingeplant werden, ohne dass drei weitere Stories mit in den Sprint gezogen werden müssen.
• Verhandelbar – die Karte lädt zu einem Gespräch ein; der Rahmen kann sich noch verschieben. Eine Geschichte, bei der jedes Detail feststeht, ist eine Vorgabe, die sich als Geschichte tarnt.
• Wertvoll – der „damit“-Satz hält einem ehrlichen „Warum?“ stand.
• Schätzbar – das Team kann den Umfang in Zahlen ausdrücken. Eine Story, deren Umfang niemand einschätzen kann, birgt eine Unbekannte; führen Sie einen Spike durch, um diese zu ermitteln.
• Klein – passt in einen Sprint, und es bleibt noch Platz übrig. Falls dies nicht der Fall ist, teilen Sie es auf.
• Prüfbar – Sie können Akzeptanzkriterien formulieren, die entweder erfüllt oder nicht erfüllt werden. „Die Seite wirkt schneller“ führt zu einem Fehlschlag; „Die Ergebnisse werden in weniger als einer Sekunde geladen“ führt zum Erfolg.

„Schätzbar“ und „klein“ sind die Kriterien, anhand derer die Stories mit dem Rest dieses Leitfadens abgeglichen werden. Eine große Streuung der Stimmen beim Planning Poker deutet in der Regel auf ein spät zutage tretendes Versagen des INVEST-Prozesses hin: Die Story war in einer Weise verhandelbar, die niemand berücksichtigt hatte, oder sie war zu umfangreich, als dass jemand den gesamten Umfang überblicken konnte.

Was eine User Story nicht ist

Keine Aufgabe. Eine Story liefert etwas, das ein Benutzer sehen kann; eine Aufgabe ist ein Schritt, den das Team unternimmt, um dorthin zu gelangen. „Mit E-Mail anmelden“ ist eine Story. „Den Sitzungsspeicher einrichten“ ist eine der dazugehörigen Aufgaben. Das Kapitel „Epic vs. Story vs. Aufgabe“ behandelt die Hierarchie und erklärt, warum Punkte ausschließlich auf der Story-Ebene vergeben werden sollten.

Kein Anforderungsdokument. Eine Anforderung soll vor Beginn der Arbeiten vollständig sein. Eine Story soll ausreichen, um den Dialog in Gang zu bringen – und nicht mehr. Wenn man Stories nach den Maßstäben von Anforderungen beurteilt („Das ist zu vage!“), verkennt man den Sinn des Konzepts: Die Unbestimmtheit ist ein Freiraum für das Urteilsvermögen des Teams.

Dies ist keine Zusage hinsichtlich der Umsetzung. Die Story legt das Ergebnis fest; das Team entscheidet über die Vorgehensweise. Wenn eine Story mit einer bereits festgelegten Lösung vorgelegt wird, ist der verhandelbare Teil von INVEST bereits weggefallen.

Wenn User Stories das falsche Werkzeug sind

Das Format hat seine Grenzen, und so zu tun, als sei dies nicht der Fall, kostet an Glaubwürdigkeit bei denjenigen, die die kniffligen Fälle verfassen müssen. In manchen Sätzen fehlt das Objekt:

• Umfassende Plattformarbeit. „Als Entwickler möchte ich das Framework aktualisieren, damit das Framework aktualisiert wird“ – das sagt nichts aus, was der Titel des Tickets nicht bereits aussagt. Formulieren Sie es als reine technische Aufgabe mit einem konkret benannten Ergebnis: Was funktioniert nicht mehr oder wird langsamer, wenn dies nicht geschieht, und was wird einfacher, wenn es geschieht?
• Fehler mit bekannter Ursache. Ein Fehlerbericht (erwartetes Verhalten, tatsächliches Verhalten, Schritte zur Reproduktion) ist eine besser geeignete Form als eine nachträglich erstellte Story. Im Kapitel über Story-Punkte wird erläutert, wann Fehler mit Story-Punkten bewertet werden.
• Forschungs-Spikes. Ein Spike besteht aus einer Fragestellung und einem festgelegten Zeitrahmen, und sein Ergebnis ist Wissen. Wenn man ihn in das Schema „Rolle – Ziel – Nutzen“ zwängt, verschleiert dies das Einzige, worauf es ankommt: das, was das Team lernen muss.
• Compliance-Arbeit. Mit einer Aufsichtsbehörde lässt sich der Umfang nicht aushandeln. Die Anforderung ist die Anforderung; halten Sie sie als solche fest.

Was all diesen Beispielen gemeinsam ist, ist die Disziplin, nicht die Formulierung: eine begründete Erklärung, warum die Arbeit wichtig ist, und eine überprüfbare Definition dessen, was als „fertig“ gilt. Behalten Sie diese beiden Aspekte bei, dann hat das Format seinen Zweck erfüllt – selbst dort, wo es eigentlich nicht zur Anwendung kommt.

Wo Geschichten auf Schätzungen treffen

Eine Story ist die Einheit der Schätzung. Sobald sie verfasst ist, durchläuft sie folgende Schritte: Das Team bespricht sie, schätzt ihren Umfang in Story-Punkten mithilfe von Planning Poker, gleicht sie mit der Definition of Ready ab und teilt sie auf, falls sich die Stimmen nicht annähern. Eine gut formulierte Story beschleunigt jeden dieser Schritte, was der praktische Grund dafür ist, warum das Format überhaupt von Bedeutung ist.

Um zu sehen, wie das Format angewendet wird, werden im Kapitel „Beispiele für User Stories“ sechzehn kommentierte User Stories vorgestellt – sowohl gute als auch schlechte. Um Ihre eigenen zu verfassen, beginnen Sie mit der Vorlage.

Häufig gestellte Fragen

Was ist eine User Story?

Eine User Story ist eine kurze, in einfacher Sprache verfasste Beschreibung einer Änderung, die aus der Perspektive der Person erzählt wird, die davon profitiert: „Als Stammkunde möchte ich mich mit meiner E-Mail-Adresse anmelden, damit ich meine Bestellhistorie einsehen kann.“ Es handelt sich bewusst nicht um eine Spezifikation. Die Karte dient als Ausgangspunkt für ein Gespräch, und die Details werden erst dann festgelegt, wenn das Team die Arbeit verfeinert und den Arbeitsaufwand einschätzt.

Was ist das User-Story-Format?

Das klassische Format lautet „Rolle – Ziel – Nutzen“: „Als [Rolle] möchte ich [Ziel], damit [Nutzen].“ Die Rolle benennt denjenigen, der den Nutzen erhält, das Ziel beschreibt die Fähigkeit aus Sicht des Nutzers, und der Nutzen ist das Argument dafür, die Arbeit überhaupt einzuplanen. Wenn niemand den „damit“-Teil vervollständigen kann, gibt es keinen Grund, die Story in das Backlog aufzunehmen.

Was sind die drei Cs von User Stories?

Karte, Gespräch, Bestätigung. Die Karte dient als Erinnerung und ist bewusst zu klein gehalten, um die Anforderung vollständig zu erfassen. Das Gespräch ist der Ort, an dem die Anforderung tatsächlich Gestalt annimmt – im Rahmen der Verfeinerung gemeinsam mit dem Team. Die Bestätigung besteht aus den Akzeptanzkriterien, die festlegen, ob die fertige Arbeit das liefert, was besprochen wurde – „bestanden“ oder „nicht bestanden“.

Wofür steht die Abkürzung INVEST?

Unabhängig, verhandelbar, wertvoll, einschätzbar, klein, testbar. Dies ist Bill Wakes Checkliste, anhand derer geprüft wird, ob eine Story bereit für die Bearbeitung ist. Die letzten drei Kriterien haben in der Praxis das größte Gewicht: Eine Story, die das Team nicht einschätzen kann, die nicht in einen Sprint passt oder deren Umsetzung durch keinen Test bestätigt werden kann, ist eine Story, die noch nicht bereit ist.

Wann sollten Sie keine User Stories verwenden?

Wenn das Format eher umständlich wirkt, anstatt Klarheit zu schaffen. Umfassende Plattformarbeiten, Fehlerbehebungen mit bekannter Ursache, Compliance-Anforderungen und Forschungsspitzen lassen sich alle besser in ihrer ursprünglichen Form darstellen. Behalten Sie die Nutzenklausel und die Akzeptanzkriterien bei; verzichten Sie auf die „Als Entwickler möchte ich“-Formulierung, wenn in dem Satz kein Nutzer erwähnt wird.

Weiterführende Literatur

• Agile Schätzung: Der umfassende Leitfaden – hier finden Sie alles zum Thema.
• Beispiele für User Stories – sechzehn kommentierte User Stories, darunter auch solche, die nicht funktionieren, sowie die Gründe dafür.
• Vorlage für User Stories und Akzeptanzkriterien – die Vorlage, ihre Varianten und ein ausgearbeitetes Beispiel bis hin zur Schätzung.
• Epos vs. Geschichte vs. Aufgabe – wo die Geschichte in der Hierarchie angesiedelt ist und auf welche Ebene verwiesen wird.
• Aufteilung von User Stories – Was ist zu tun, wenn eine Story den „Small Test“ nicht besteht?