Was ist eine User Story?
Eine User Story ist eine kurze Beschreibung einer Anforderung aus Sicht derjenigen, die sie nutzen. Statt technische Funktionen aufzulisten, beschreibt sie, wer etwas erreichen möchte und warum. Das lenkt den Blick auf den Nutzen und erleichtert die Priorisierung. Der Scrum Guide schreibt bewusst kein Format für Einträge im Product Backlog vor; Beschreibung, Reihenfolge und Grösse sind Attribute, die je nach Arbeitsbereich variieren [1]. User Stories sind deshalb eine ergänzende Technik, die sich in vielen Teams bewährt hat.
Das Agile Business Consortium bezeichnet User Stories in seinem DSDM-Rahmenwerk als sehr wirksame Form, Anforderungen agil zu definieren [2]. Ihre Stärke liegt darin, dass sie bewusst unvollständig sind: Eine Story ist ein Versprechen für ein Gespräch zwischen Fachleuten und Team, nicht eine abschliessende Spezifikation. Dieser Gedanke entspricht dem Agilen Manifest, das Zusammenarbeit und Interaktion höher gewichtet als umfassende Dokumentation [3].
Wie ist eine User Story aufgebaut?
Das verbreitetste Format lautet: «Als Rolle möchte ich Ziel, damit Nutzen.» Die Rolle beschreibt, wer die Funktion nutzt, möglichst konkret, etwa «Buchhalterin» statt «Benutzer». Das Ziel beschreibt, was die Person tun möchte. Der Nutzen beschreibt, warum, und ist oft der wichtigste Teil, weil er Raum für alternative Lösungen lässt. Ein Beispiel: «Als Projektleiterin möchte ich alle Zeiteinträge eines Monats als Datei exportieren, damit ich sie der Buchhaltung für die Abrechnung übergeben kann.»
Ein bekanntes Merkmal von User Stories sind die drei C: Card, Conversation, Confirmation. Die Karte enthält die kurze Beschreibung, das Gespräch klärt Details zwischen Fachleuten und Team, die Bestätigung erfolgt über Akzeptanzkriterien, die festlegen, wann die Story erfüllt ist. Wer nur die Karte schreibt und das Gespräch auslässt, verliert den wichtigsten Teil.
Woran erkennt man eine gute User Story?
| Kriterium | Bedeutung | Prüffrage |
|---|---|---|
| Independent (unabhängig) | möglichst wenig Abhängigkeiten zu anderen Stories | Kann die Story einzeln umgesetzt und geliefert werden? |
| Negotiable (verhandelbar) | Details werden im Gespräch geklärt | Lässt die Story Raum für Lösungsvarianten? |
| Valuable (wertvoll) | stiftet Nutzen für Nutzende oder Auftraggeber | Würde jemand den Nutzen bemerken? |
| Estimable (schätzbar) | das Team kann den Aufwand einschätzen | Versteht das Team genug, um zu schätzen? |
| Small (klein) | passt in einen Sprint, idealerweise in wenige Tage | Kann sie in einem Sprint fertig werden? |
| Testable (testbar) | es ist überprüfbar, ob sie erfüllt ist | Gibt es klare Akzeptanzkriterien? |
Die INVEST-Kriterien gehen auf Bill Wake zurück und sind eine praktische Prüfliste für das Refinement. Nicht jede Story erfüllt alle Kriterien perfekt, aber grosse Abweichungen sind ein Signal: Eine Story, die nicht schätzbar ist, braucht mehr Klärung; eine, die nicht klein ist, sollte zerlegt werden; eine, die nicht testbar ist, braucht Akzeptanzkriterien.
Wie schreibt man Akzeptanzkriterien?
Akzeptanzkriterien legen fest, unter welchen Bedingungen eine Story als erfüllt gilt. Sie sind die Grundlage für Tests und für die Abnahme durch den Product Owner. Eine verbreitete Form ist das Muster Gegeben-Wenn-Dann, im Englischen Given-When-Then, das aus der verhaltensgetriebenen Entwicklung stammt. Es beschreibt eine Ausgangssituation, eine Handlung und das erwartete Ergebnis.
| Gegeben | Wenn | Dann |
|---|---|---|
| ich bin als Projektleiterin angemeldet und habe Zeiteinträge im Oktober | ich den Zeitraum Oktober wähle und auf Export klicke | erhalte ich eine Datei mit allen Einträgen des Oktobers inklusive Projekt, Person, Datum und Dauer |
| ich habe keine Einträge im gewählten Zeitraum | ich auf Export klicke | erscheint der Hinweis, dass keine Einträge vorhanden sind, und es wird keine leere Datei erzeugt |
| ich bin als Teammitglied ohne Leitungsrolle angemeldet | ich den Export aufrufe | enthält die Datei nur meine eigenen Einträge |
Akzeptanzkriterien unterscheiden sich von der Definition of Done. Die Definition of Done gilt für alle Einträge, etwa «getestet, dokumentiert, im Hauptzweig integriert». Akzeptanzkriterien gelten nur für eine bestimmte Story. Beide müssen erfüllt sein, damit eine Story als fertig gilt. Eine Übersicht bietet das Glossar unter Akzeptanzkriterien und Definition of Done.
Wie zerlegt man zu grosse Stories?
Grosse Stories, oft Epics genannt, müssen vor der Umsetzung in kleinere zerlegt werden. Wichtig ist, vertikal zu schneiden: Jede Teilstory sollte einen kleinen, aber vollständigen Nutzen liefern, statt nach technischen Schichten wie Oberfläche, Logik und Datenbank getrennt zu werden. Bewährte Zerlegungsmuster helfen dabei.
- Nach Arbeitsschritten: Bestellung anlegen, bezahlen, bestätigen als einzelne Stories.
- Nach Geschäftsregeln: zuerst die Standardregel, dann Sonderfälle wie Rabatte oder Ausnahmen.
- Nach Datenvarianten: zuerst ein Dateiformat, später weitere.
- Nach Glücks- und Fehlerpfad: zuerst der normale Ablauf, danach Fehlerbehandlung.
- Nach Operationen: anzeigen, anlegen, ändern, löschen getrennt.
- Nach Nutzergruppen: zuerst für interne Nutzende, später für Kunden.
- Mit einem Spike: kurze, zeitlich begrenzte Untersuchung, wenn die Lösung unklar ist.
Kleine Stories haben viele Vorteile: Sie lassen sich genauer schätzen, früher liefern und besser priorisieren. Bei der Priorisierung mit WSJF erhalten kleine, wertvolle Teile eines grossen Vorhabens oft einen deutlich besseren Wert als das Vorhaben als Ganzes, siehe Backlog priorisieren. Das Glossar bietet unter Story Splitting weitere Hinweise.
Typische Fehler beim Schreiben von User Stories
| Fehler | Beispiel | Besser |
|---|---|---|
| Technische Aufgabe statt Nutzen | Als Entwickler möchte ich eine Tabelle anlegen | Story aus Sicht der Nutzenden, Tabelle ist Teil der Umsetzung |
| Rolle zu allgemein | Als Benutzer möchte ich … | Als Buchhalterin möchte ich … |
| Nutzen fehlt | Als Kunde möchte ich einen Export | … damit ich die Daten in meiner Buchhaltung weiterverarbeiten kann |
| Lösung vorgegeben | … möchte ich einen blauen Knopf oben rechts | Ziel beschreiben, Lösung im Gespräch finden |
| Keine Akzeptanzkriterien | Story ohne überprüfbare Bedingungen | zwei bis fünf Kriterien im Muster Gegeben-Wenn-Dann |
Wie hilft Story Mapping beim Überblick?
Ein flacher Backlog mit hunderten Stories verliert schnell den Zusammenhang. Story Mapping ordnet Stories entlang der Abläufe der Nutzenden: horizontal die Schritte, etwa suchen, auswählen, bestellen, bezahlen; vertikal darunter die Stories zu jedem Schritt, nach Priorität geordnet. Eine horizontale Linie über die Karte markiert, was in ein erstes Release gehört. So entsteht ein Überblick, der zeigt, ob ein Release einen durchgängigen Ablauf ermöglicht. Mehr dazu im Glossar unter Story Mapping.
User Stories im Werkzeug pflegen
Im Projekttool sollte jede Story Beschreibung, Akzeptanzkriterien, Schätzung, Priorität und Status haben und mit Aufgaben, Zeiten und Gesprächsnotizen verknüpft sein. In Flenio lassen sich Stories als Aufgaben mit Beschreibung und Checklisten für Akzeptanzkriterien führen, auf Boards planen und mit erfassten Zeiten verbinden. Wer Anforderungen ausführlicher beschreiben muss, etwa für Ausschreibungen, findet ergänzende Methoden im Bereich Requirements Engineering. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.
Wann ist eine Story bereit für den Sprint?
Viele Teams nutzen eine Definition of Ready, um festzulegen, wann eine Story so weit geklärt ist, dass sie in einen Sprint aufgenommen werden kann. Typische Kriterien sind: Die Story ist verstanden, hat Akzeptanzkriterien, ist geschätzt und klein genug für einen Sprint, und Abhängigkeiten sind bekannt. Der Scrum Guide spricht davon, dass Einträge, die in einem Sprint fertig werden können, nach dem Refinement bereit für die Auswahl im Sprint Planning sind.
Eine Definition of Ready sollte nicht zur Bürokratie werden. Wenn sie so streng ist, dass kaum eine Story sie erfüllt, verzögert sie die Arbeit, statt sie zu verbessern. Sie ist ein Hilfsmittel für das Refinement, kein Tor, an dem Stories abgewiesen werden. Wie die Grösse von Stories geschätzt wird, beschreibt der Beitrag Agile Schätzverfahren.
Wie werden nicht-funktionale Anforderungen behandelt?
Nicht jede Anforderung passt in das Story-Format. Anforderungen an Leistung, Sicherheit, Barrierefreiheit oder Datenschutz gelten oft für viele Stories gleichzeitig. Sie lassen sich auf drei Arten behandeln: als Teil der Definition of Done, wenn sie für alle Einträge gelten, etwa Barrierefreiheit nach einem bestimmten Standard; als Akzeptanzkriterium einzelner Stories, wenn sie nur dort relevant sind; oder als eigene Einträge, wenn sie eigenständige Arbeit erfordern, etwa eine Sicherheitsprüfung. Wichtig ist, dass sie nicht vergessen werden, weil sie in keinem Format auftauchen.
Hilfreich ist eine kurze Liste der wichtigsten nicht-funktionalen Anforderungen, die beim Refinement jeder Story kurz geprüft wird. So werden Sicherheit, Datenschutz und Barrierefreiheit nicht zum Nachgedanken, sondern von Anfang an mitgedacht und im Aufwand berücksichtigt.
Am Ende gilt: Eine User Story ist dann gut, wenn das Team nach dem Gespräch genau weiss, was zu tun ist, und der Product Owner anhand der Akzeptanzkriterien eindeutig entscheiden kann, ob sie erfüllt ist.