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, wenn das Team die Story verfeinert, ihre Akzeptanzkriterien festlegt und ihren Umfang bestimmt.

Alles andere in diesem Leitfaden basiert auf Stories. Sie sind das, was Planning Poker bewertet, woran Story-Punkte gemessen werden und was aufgeteilt wird, wenn die Schätzung nicht konvergiert. Ein Team, das schlechte Stories verfasst, wird 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 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 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 dafür, dass die Aufgabe in den Plan aufgenommen wird. Wenn niemand sie fertigstellen kann, ist die Aufgabe nicht gerechtfertigt, und durch das Aufschreiben des Satzes stellen Sie dies bereits vor Beginn des Sprints fest – 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 entspricht den Abnahmekriterien: den Bedingungen für „bestanden“ oder „nicht bestanden“, anhand derer festgestellt wird, ob das fertige Ergebnis den im Gespräch vereinbarten Anforderungen entspricht. Das Kapitel zur User-Story-Vorlage zeigt die beiden geeigneten Formate auf, und das Kapitel zu den Abnahmekriterien behandelt deren Erstellung ausführlich.

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 Arbeit ist. Eine gute Story ist:

• Unabhängig: Kann eigenständig geplant 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, bei der jedes Detail feststeht, ist eine Vorgabe, die sich als Geschichte tarnt.
• Aussagekräftig: 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 zum 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 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 der INVEST-Methode 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 erläutert, 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. Wer Stories anhand von Anforderungsstandards bewertet („Das ist zu vage!“), verkennt 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 die Vorgehensweise. Wenn eine Story mit einer bereits festgelegten Lösung eingereicht wird, entfällt der verhandelbare Teil von INVEST.

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“ sagt nichts aus, was der Titel des Tickets nicht bereits aussagt. Formulieren Sie es als konkrete technische Aufgabe mit einem 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) eignet sich besser als eine nachträglich angepasste Story. Im Kapitel über Story-Punkte wird erläutert, wann Fehler mit Punkten bewertet 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 man 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ündung, 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, bewertet ihren Umfang in Story-Punkten mithilfe von Planning Poker, überprüft sie anhand der Definition der Fertigstellung 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, 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 bezeichnet denjenigen, der den Nutzen erhält, das Ziel beschreibt die Fähigkeit aus Sicht des Benutzers, und der Nutzen ist das Argument dafür, die Arbeit überhaupt zu planen. Wenn niemand den Teil „damit“ vervollständigen kann, gibt es keinen Grund, die Story in das 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, 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 – also „bestanden“ oder „nicht bestanden“.

Wofür steht die Abkürzung INVEST?

Unabhängig, verhandelbar, wertvoll, einschätzbar, klein, testbar. Dies ist Bill Wakes Checkliste, um festzustellen, ob eine Story bereit für die Bearbeitung ist. Die letzten drei Punkte 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 Formulierung „Als Entwickler möchte ich“, wenn in dem Satz kein Nutzer genannt 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 fehlschlagen, 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?