Eine User Story beschreibt aus Sicht einer Rolle einen gewünschten Nutzen: «Als [Rolle] möchte ich [Funktion], damit [Nutzen]». Der dritte Teil ist der wichtigste — ohne ihn ist die Story eine Aufgabe im Story-Format, und die Frage nach der Priorität lässt sich nicht beantworten.
Das Format
Die verbreitete Form lautet: «Als [Rolle] möchte ich [etwas tun können], damit [Nutzen]». Alle drei Teile tragen, aber unterschiedlich stark.
| Teil | Beantwortet | Was fehlt ohne ihn |
|---|---|---|
| Als [Rolle] | Für wen? | Die Perspektive — man baut für niemanden Bestimmten |
| möchte ich [Funktion] | Was? | Der Inhalt |
| damit [Nutzen] | Wozu? | Die Priorisierbarkeit und der Spielraum bei der Lösung |
Der dritte Teil wird am häufigsten weggelassen oder mit einer Tautologie gefüllt («damit ich X tun kann»). Damit geht der eigentliche Wert verloren: Der Nutzen ist die Begründung, warum diese Story überhaupt Vorrang haben soll — und er eröffnet oft eine einfachere Lösung als die genannte Funktion.
Die Rolle konkret machen
«Als Nutzer möchte ich …» ist die häufigste und schwächste Rollenangabe. Sie enthält keine Information, weil praktisch jede Anforderung von irgendeinem Nutzer kommt.
Konkrete Rollen verändern das Ergebnis: «Als Sachbearbeiterin, die täglich vierzig Anträge prüft» führt zu anderen Lösungen als «Als Bürger, der einmal jährlich einen Antrag stellt». Erstere braucht Tastaturbedienung und Massenverarbeitung, Letzterer Führung und Erklärung.
Wenn Sie die Rollenangabe durch eine andere Rolle ersetzen können, ohne dass sich die Story ändern müsste, ist die Rolle zu unspezifisch.
Akzeptanzkriterien
Die Story beschreibt den Bedarf, die Akzeptanzkriterien beschreiben, woran die Erfüllung erkennbar ist. Sie gehören zur Story und werden mit dem Product Owner abgestimmt, nicht vom Team allein festgelegt.
Bewährt ist eine Formulierung nach Ausgangslage, Handlung und Ergebnis: «Gegeben ein Antrag im Status Entwurf, wenn die Nutzerin auf Einreichen klickt und Pflichtfelder fehlen, dann werden die fehlenden Felder markiert und der Antrag bleibt im Entwurf.» Solche Kriterien lassen sich unmittelbar in Testfälle überführen.
INVEST als Prüfraster
- Independent — möglichst unabhängig von anderen Stories umsetzbar.
- Negotiable — beschreibt den Bedarf, nicht die technische Lösung.
- Valuable — liefert erkennbaren Nutzen für jemanden.
- Estimable — das Team kann den Aufwand grob einschätzen.
- Small — passt in einen Sprint, besser in wenige Tage.
- Testable — die Erfüllung ist überprüfbar.
Das Raster ist eine Checkliste, kein Gesetz. Vollständige Unabhängigkeit ist selten erreichbar, und das ist in Ordnung. Wertvoll ist es dort, wo mehrere Punkte gleichzeitig verletzt sind — das ist ein zuverlässiger Hinweis auf eine Story, die noch Arbeit braucht.
Zu grosse Stories teilen
Geteilt wird entlang des Nutzens, nicht entlang der Technik. Eine Teilung in «Datenbank», «Schnittstelle» und «Oberfläche» erzeugt Teile, die einzeln niemandem nützen — erst alle drei zusammen liefern etwas.
Brauchbare Schnittlinien: erst der Standardfall, dann die Sonderfälle. Erst eine Datenquelle, dann weitere. Erst die manuelle Variante, dann die Automatisierung. Erst das Notwendige, dann der Komfort. Jeder dieser Teile ist für sich einsetzbar — und genau das ist das Kriterium.
Häufige Fragen
- Wie schreibt man eine User Story?
- Im Format «Als [Rolle] möchte ich [Funktion], damit [Nutzen]». Der dritte Teil ist der wichtigste: Ohne ihn lässt sich die Priorität nicht begründen, und oft zeigt der Nutzen eine einfachere Lösung als die genannte Funktion.
- Was bedeutet INVEST bei User Stories?
- Independent, Negotiable, Valuable, Estimable, Small, Testable — ein Prüfraster für die Qualität einer Story. Es ist eine Checkliste, kein Gesetz; aussagekräftig ist vor allem, wenn mehrere Punkte gleichzeitig verletzt sind.
- Wie teilt man zu grosse User Stories?
- Entlang des Nutzens, nicht entlang der Technik. Brauchbare Schnittlinien sind: erst Standardfall dann Sonderfälle, erst eine Datenquelle dann weitere, erst manuell dann automatisiert. Jeder Teil muss für sich einsetzbar sein.