User Stories sind das bekannteste Werkzeug agiler Anforderungsarbeit und eines der am häufigsten missverstandenen. Eine gute Story ist kein verkürztes Pflichtenheft, sondern der Anlass für ein Gespräch, festgehalten so, dass am Ende prüfbar ist, ob das Ziel erreicht wurde.
Der Aufbau
Das klassische Muster lautet: Als Rolle möchte ich ein Ziel erreichen, damit ein Nutzen entsteht. Zum Beispiel: Als Buchhalterin möchte ich offene Rechnungen nach Fälligkeit filtern, damit ich Mahnungen rechtzeitig auslöse. Die Rolle zwingt zum Perspektivwechsel, das Ziel beschreibt das Was ohne das Wie, und der Nutzen erklärt, warum die Story überhaupt wichtig ist — er ist die Grundlage für die Priorisierung.
Gute Stories: INVEST
Eine bewährte Prüfliste ist INVEST: unabhängig von anderen Stories, verhandelbar im Detail, wertvoll für Nutzer oder Kunden, schätzbar, klein genug für einen Sprint und testbar. Stories, die zu gross sind, werden entlang des Nutzens geschnitten, nicht entlang technischer Schichten: lieber zuerst ein Filter nach Fälligkeit, dann einer nach Kunde, als zuerst die Datenbank, dann die Oberfläche.
Akzeptanzkriterien
Akzeptanzkriterien beschreiben konkret, woran man erkennt, dass die Story erfüllt ist. Ein verbreitetes Format ist Given-When-Then: Gegeben sind drei Rechnungen mit unterschiedlicher Fälligkeit; wenn die Buchhalterin nach überfällig filtert; dann werden nur die Rechnungen mit Fälligkeit vor heute angezeigt. Gute Kriterien decken auch Randfälle und Fehlerfälle ab und sind so formuliert, dass sie sich automatisiert testen lassen.
Abgrenzung zur Definition of Done
Akzeptanzkriterien gelten für eine einzelne Story. Die Definition of Done gilt für alle: Code reviewt, Tests geschrieben, Dokumentation nachgeführt, deployt. Eine Story ist erst fertig, wenn beides erfüllt ist. Wer die beiden vermischt, wiederholt in jeder Story dieselben Kriterien oder vergisst die allgemeinen Qualitätsanforderungen.
Typische Fehler
Stories aus Sicht des Systems statt des Nutzers. Rollen wie „Als Nutzer“, die nichts aussagen. Fehlender Nutzen. Akzeptanzkriterien, die erst während der Umsetzung entstehen. Und Stories, die eigentlich technische Aufgaben sind. In regulierten oder öffentlichen Projekten, etwa nach HERMES, werden Stories häufig mit formalen Anforderungen kombiniert; wie das sauber gelingt, beschreibt der Eintrag zum Requirements Engineering.