User Stories Anforderungen aus Sicht derer, die das Produkt nutzen

Eine User Story ist eine Anforderung in einem Satz — formuliert aus der Sicht des Nutzers, nicht aus der Sicht der Technik. „Als Kundin möchte ich mein Passwort zurücksetzen können, damit ich mich nicht jedes Mal an den Support wenden muss." So einfach, so wirkungsvoll. User Stories zwingen dich, über den Nutzen nachzudenken, bevor du über die Lösung nachdenkst.

User Stories auf einen Blick

Format
„Als [Rolle] möchte ich [Funktion], damit [Nutzen]"
Umfang
Genau eine Story pro Backlog-Eintrag
Ergänzung
Akzeptanzkriterien definieren, wann die Story erfüllt ist
Herkunft
Extreme Programming (Kent Beck), in Scrum übernommen
USER STORY Als Kundin möchte ich mein Passwort zurücksetzen können, damit ich nicht den Support kontaktieren muss. Akzeptanzkriterien: E-Mail-Link funktioniert, neues Passwort in 30s aktiv
Eine User Story: Rolle, Funktion und Nutzen in einem Satz

Wie schreibst du eine gute User Story?

Das Standardformat hat sich seit zwei Jahrzehnten bewährt und besteht aus drei Teilen:

  • Als [Rolle] — Wer braucht diese Funktion? Nicht „der User", sondern konkret: Kundin, Admin, neuer Mitarbeiter.
  • möchte ich [Funktion] — Was soll passieren? Beschreibe das gewünschte Verhalten, nicht die technische Lösung.
  • damit [Nutzen] — Warum ist das wichtig? Der Nutzen zwingt alle Beteiligten, über den echten Wert nachzudenken.

Beispiele, die funktionieren:

  • „Als Projektleiterin möchte ich den Sprint-Fortschritt als Burndown Chart sehen, damit ich rechtzeitig eingreifen kann, wenn wir vom Ziel abweichen."
  • „Als Neukunde möchte ich mich mit meinem Google-Konto registrieren, damit ich kein neues Passwort anlegen muss."

Was sind Akzeptanzkriterien?

Eine User Story ohne Akzeptanzkriterien ist wie ein Rezept ohne Mengenangaben — du weißt ungefähr, was rauskommen soll, aber nicht, wann es fertig ist. Akzeptanzkriterien definieren messbar, wann eine Story erfüllt ist.

Typisches Format: „Gegeben [Ausgangslage], wenn [Aktion], dann [erwartetes Ergebnis]." Beispiel:

  • Gegeben: Der Nutzer ist auf der Login-Seite.
  • Wenn: Er klickt auf „Passwort vergessen" und gibt seine E-Mail ein.
  • Dann: Er erhält innerhalb von 60 Sekunden eine E-Mail mit einem Zurücksetz-Link.

Woran erkennst du eine schlechte User Story?

Das INVEST-Akronym hilft dir bei der Qualitätskontrolle. Jede gute User Story ist:

  • Independent — unabhängig von anderen Stories umsetzbar
  • Negotiable — verhandelbar, kein starrer Vertrag
  • Valuable — liefert echten Wert für den Nutzer oder das Geschäft
  • Estimable — das Team kann den Aufwand schätzen
  • Small — klein genug für einen Sprint
  • Testable — das Ergebnis lässt sich prüfen

Wie zerlegst du große Stories?

Zu große Stories (auch „Epics" genannt) müssen aufgeteilt werden, bevor sie in einen Sprint kommen. Bewährte Strategien:

  • Nach Workflow-Schritten: Eine Story pro Schritt (z.B. Registrierung, E-Mail-Bestätigung, Profil-Erstellung).
  • Nach Geschäftsregeln: Die Happy-Path-Version zuerst, Sonderfälle als eigene Stories.
  • Nach Datentypen: Erst ein Datentyp (z.B. nur Texte), dann erweitern (Bilder, Videos).

Der Product Owner und das Team teilen Stories im Backlog Refinement gemeinsam auf — nicht einseitig.