Von der User Story zum Abnahmekriterium: Given/When/Then richtig gemacht

Eine User Story ist eine Anforderung in Freizeitkleidung. Sie ist bewusst klein und bewusst informell — aber sie ist immer noch eine Anforderung und hat dieselbe eine Aufgabe: die Lücke zwischen dem Gewünschten und dem Gebauten zu schließen.

Der Haken ist, dass eine Story allein diese Aufgabe nicht erfüllt. Eine Story ohne Abnahmekriterien ist ein Wunsch. Dieser Beitrag zeigt, wie man beides schreibt — die Story, die das Gespräch eröffnet, und die Kriterien, die es beenden.

Eine User Story ist ein Versprechen, keine Spezifikation

Die klassische Form: „Als <Rolle> möchte ich <Fähigkeit>, damit <Nutzen>.“

Beispiel: „Als Projektverantwortlicher möchte ich meine Anforderungen als PDF exportieren, damit ich sie mit einem Kunden teilen kann, der das Werkzeug nicht nutzt.“

Beachten Sie, was die Story NICHT sagt: Sie sagt nicht, wie der Export gebaut wird, welche Bibliothek verwendet wird oder wie das PDF aussieht. Sie benennt den Bedarf und überlässt das Wie dem Team. Eine Story ist ein Wertversprechen, keine Implementierung.

Abnahmekriterien machen sie testbar

Die Abnahmekriterien sind der Ort, an dem die Story konkret wird. Sie sind die Bedingungen, die erfüllt sein müssen, damit die Story als erledigt gilt. Ist die Story ein Versprechen, sind die Kriterien die Definition von „gehalten“.

Das sauberste Format ist Angenommen/Wenn/Dann (aus Gherkin): Angenommen ein Ausgangszustand, Wenn etwas geschieht, Dann muss das System auf eine bestimmte, beobachtbare Weise reagieren.

Angenommen/Wenn/Dann, richtig gemacht

Ein vollständiges Beispiel:

Angenommen ein Dokument mit 120 Anforderungen — Wenn der Verantwortliche auf „Als PDF exportieren“ klickt — Dann erzeugt das System ein PDF mit allen 120 Anforderungen, und das PDF enthält die Abschnittsnummerierung.

Drei Regeln halten es ehrlich: ein verifizierbares Ergebnis pro Dann; konkrete Werte statt vager Wörter; und keine Implementierungsdetails (die Kriterien sagen WAS, niemals WIE).

• Angenommen — die Vorbedingungen: der Zustand, die Daten, der angemeldete Benutzer.
• Wenn — die einzelne Aktion oder das Ereignis, das das Verhalten auslöst.
• Dann — das beobachtbare, testbare Ergebnis.

INVEST: sechs Prüfungen für eine gute Story

• Independent (unabhängig) — sie lässt sich eigenständig bauen und ausliefern.
• Negotiable (verhandelbar) — sie erfasst das Ziel, nicht den Entwurf.
• Valuable (wertvoll) — sie liefert etwas, das der Benutzer wirklich will.
• Estimable (schätzbar) — das Team kann ihren Umfang einschätzen.
• Small (klein) — sie passt bequem in einen Sprint.
• Testable (testbar) — man kann auf Abnahmekriterien zeigen, die sie belegen.

Häufige Fehler

• Das WIE in die Kriterien schreiben (z. B. „die PDF-Bibliothek X verwenden“) — das ist Entwurf, keine Abnahme.
• Mehrere Ergebnisse in ein Szenario packen — aufteilen, sonst erkennt man nicht, welches gescheitert ist.
• Vages Dann („das System sollte schnell sein“) — durch eine Zahl ersetzen.
• Stories, die so groß sind, dass man sie nicht schätzen kann — entlang des Nutzens aufteilen, nicht entlang der Arbeit.

Ein vollständiges Beispiel

Schlecht: „Als Benutzer möchte ich exportieren, damit ich Dinge speichern kann. Abnahme: Der Export soll funktionieren und schnell sein.“

Gut: „Als Projektverantwortlicher möchte ich meine Anforderungen als PDF exportieren, damit ich sie mit einem Kunden teilen kann.“ — Angenommen ein Dokument mit 120 Anforderungen, Wenn der Verantwortliche auf „Als PDF exportieren“ klickt, Dann erzeugt das System ein PDF mit allen 120 Anforderungen. Und das PDF enthält die Abschnittsnummerierung und die Nachverfolgbarkeitsmatrix. Und der Export ist innerhalb von 2 Sekunden abgeschlossen.

Die erste Version ist ein Wunsch und wird einen Streit beginnen. Die zweite ist ein Versprechen, das ein Tester halten oder brechen kann — genau das macht sie nützlich.