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 zu führen, und die Details ergeben sich erst, wenn das Team die Story verfeinert, ihre Akzeptanzkriterien festlegt und ihren Umfang ermittelt.

Alles andere in diesem Leitfaden basiert auf Stories. Sie bilden die Grundlage für die Größenangaben beim Planning Poker, sie dienen als Bezugsgröße für Story-Punkte und sie werden aufgeteilt, wenn sich die Schätzung nicht angleicht. Ein Team, das schlechte Stories verfasst, wird schlechte Schätzungen abgeben, 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 [Vorteil] 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 Fähigkeit 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 Grund, aus dem Teams eine Klausel als Erstes streichen, und er ist es, der der Karte ihren Platz im Backlog sichert. 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 von Bedeutung ist.

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 das, 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 schriftlich festgehalten 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 in den Sprint mit einbezogen werden müssen.
• Verhandelbar: Die Karte regt zum Gespräch an; der Rahmen kann sich noch verschieben. Eine Geschichte, in der jedes Detail feststeht, ist eine Vorgabe, die sich als Geschichte tarnt.
• Bedeutsam: 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 bestanden oder nicht bestanden werden. „Die Seite wirkt schneller“ führt zu einem Nichtbestehen; „Die Ergebnisse werden in weniger als einer Sekunde geladen“ führt zum Bestehen.

„Schätzbar“ und „klein“ sind die Kriterien, anhand derer die Stories mit den übrigen Teilen 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 ihrer 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, der dem Urteilsvermögen des Teams vorbehalten ist.

Keine Zusage zur Umsetzung. Die Story legt das Ergebnis fest; das Team entscheidet über das „Wie“. 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 Sätze 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 Arbeit 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 angepasste Story. Im Kapitel über Story-Punkte wird erläutert, wann Fehler mit Story-Punkten versehen werden.
• Forschungs-Spikes. Ein Spike besteht aus einer Frage und einem festgelegten Zeitrahmen, und sein Ergebnis ist Wissen. Wenn man ihn in die 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 können Sie nicht über den Umfang verhandeln. 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 seine Aufgabe 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 anhand von Story-Punkten mit Planning Poker, prüft sie anhand der „Ready“-Definition und teilt sie auf, falls sich die Stimmen nicht angleichen. Eine gut formulierte Story beschleunigt jeden dieser Schritte – und genau das ist der praktische Grund, 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, nutzen Sie bitte die Vorlage als Ausgangspunkt.

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 den Backlog aufzunehmen.

Was sind die drei Cs der 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 Fertigstellung 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 steht die Geschichte in der Hierarchie, und auf welche Ebene wird verwiesen?
• Aufteilung von User Stories: Was ist zu tun, wenn eine Story den „Small Test“ nicht besteht?