User Stories

User Stories sind keine Anforderungsdokumente. Sie sind Platzhalter für Gespräche.

Ron Jeffries hat dies als die „3 Cs" zusammengefasst:

Card: Eine kurze Beschreibung, die auf eine Karteikarte passt. „Als Benutzer möchte ich mein Passwort zurücksetzen, damit ich wieder Zugriff auf mein Konto erhalte."

Conversation: Der Dialog zwischen Entwicklern und Kunden, der die Details ausarbeitet. Was bedeutet „zurücksetzen"? E-Mail-Link? SMS-Code? Sicherheitsfragen?

Confirmation: Die Akzeptanzkriterien, die Ihnen sagen, wann die Story fertig ist. „Gegeben eine gültige E-Mail, wenn ich auf ‚Passwort zurücksetzen' klicke, dann erhalte ich innerhalb von 1 Minute eine E-Mail mit einem Reset-Link."

Die Karte ist nicht die Anforderung. Das Gespräch ist die Anforderung. Die Karte ist nur eine Erinnerung, das Gespräch zu führen.

Das klassische Story-Format lautet:

Als [Benutzertyp] möchte ich [eine Fähigkeit] damit [geschäftlicher Wert]

Zum Beispiel:

• Als Käufer möchte ich Produkte nach Preis filtern, damit ich Artikel in meinem Budget finden kann.
• Als Admin möchte ich Benutzerdaten als CSV exportieren, damit ich Trends in Excel analysieren kann.
• Als Gast möchte ich ohne Kontoerstellung zur Kasse gehen, damit ich schnell kaufen kann.

Die „damit"-Klausel ist entscheidend. Sie erklärt, warum die Funktion wichtig ist. Das hilft Entwicklern, gute Entscheidungen über die Implementierung zu treffen, und hilft Product Ownern bei der Priorisierung.

Schlechte Stories lassen das Warum weg:

• „Als Benutzer möchte ich einen blauen Button." (Warum? Was macht er?)
• „Suchfunktionalität implementieren." (Für wen? Welcher Wert?)

Gute Stories verbinden Funktionen mit Wert:

• „Als wiederkehrender Kunde möchte ich meinen letzten Einkauf erneut bestellen, damit ich wieder kaufen kann, ohne zu suchen."

Das INVEST-Akronym beschreibt Qualitäten guter Stories:

Independent (Unabhängig): Stories können in beliebiger Reihenfolge entwickelt werden. Keine Abhängigkeiten zwischen Stories.

Negotiable (Verhandelbar): Der Umfang ist flexibel. Details werden durch Gespräche ausgehandelt.

Valuable (Wertvoll): Jede Story liefert Wert für Benutzer. Keine „technischen Stories" ohne Benutzernutzen.

Estimable (Schätzbar): Das Team kann einschätzen, wie groß sie ist. Falls nicht, braucht die Story Klärung oder Aufteilung.

Small (Klein): Eine Story sollte weniger als eine Woche Arbeit bedeuten. Idealerweise ein paar Tage.

Testable (Testbar): Es gibt klare Akzeptanzkriterien. Man kann überprüfen, wann sie fertig ist.

Wenn eine Story gegen INVEST verstößt, beheben Sie es:

• Abhängige Stories: Kombinieren Sie sie oder brechen Sie die Abhängigkeit auf
• Große Stories: In kleinere Teile aufteilen
• Nicht schätzbare Stories: Erst einen Spike durchführen, um Unsicherheit zu reduzieren
• Nicht testbare Stories: Akzeptanzkriterien klären

Große Stories müssen aufgeteilt werden. Aber wie?

Nach Workflow-Schritt aufteilen: „Benutzer kann Checkout abschließen" →

• Benutzer kann Artikel in den Warenkorb legen
• Benutzer kann Lieferadresse eingeben
• Benutzer kann Zahlungsinformationen eingeben
• Benutzer kann bestätigen und Bestellung aufgeben

Nach Datenvariation aufteilen: „Benutzer kann für Bestellung bezahlen" →

• Benutzer kann mit Kreditkarte bezahlen
• Benutzer kann mit PayPal bezahlen
• Benutzer kann mit Geschenkkarte bezahlen

Nach Operation aufteilen: „Benutzer kann sein Profil verwalten" →

• Benutzer kann sein Profil ansehen
• Benutzer kann seinen Namen bearbeiten
• Benutzer kann seine E-Mail ändern
• Benutzer kann sein Konto löschen

Nach Performance aufteilen: „Suche liefert Ergebnisse schnell" →

• Suche liefert Ergebnisse (beliebige Geschwindigkeit)
• Suche liefert Ergebnisse in unter 2 Sekunden

Jede aufgeteilte Story sollte unabhängig auslieferbar sein. Wenn Sie keine teilweise Kreditkartenunterstützung ausliefern können (nur Visa, nicht Mastercard), ist das trotzdem eine Aufteilung – Sie liefern Wert inkrementell.

Das ist es wert, wiederholt zu werden: Stories sind keine Spezifikationen.

Traditionelle Anforderungsdokumente versuchen, jedes Detail im Voraus zu spezifizieren. Das scheitert, weil:

• Man nicht alle Details kennen kann, bevor man anfängt
• Geschriebene Dokumente von verschiedenen Lesern unterschiedlich interpretiert werden
• Spezifikationen veralten, wenn sich das Verständnis ändert
• Sie Gespräche entmutigen

Stories akzeptieren Unsicherheit. Die Karte erfasst die Absicht. Das Gespräch füllt Details genau rechtzeitig aus. Die Bestätigung verifiziert das Verständnis.

Der Kunde bleibt die ganze Zeit involviert. Wenn Entwickler Fragen haben, fragen sie den Kunden – nicht das Dokument. Das hält das Team ausgerichtet und passt sich dem Lernen an.

Stories fördern auch das Aufschieben von Entscheidungen. Man muss nicht jeden Grenzfall im Voraus entscheiden. Behandeln Sie zuerst den Hauptpfad. Wenn Sie auf einen Grenzfall stoßen, führen Sie dann ein Gespräch.

Das ist XPs Ansatz für Anforderungen: gerade genug, genau rechtzeitig, durch Gespräche.