Akzeptanzkriterien: So formulieren Sie sie (mit Beispielen)

Akzeptanzkriterien sind die Bedingungen, die eine User Story erfüllen muss, damit das Team sie als lieferbereit einstuft. Wenn Sie sie richtig formulieren, reduzieren Sie Nacharbeit, Missverständnisse und unerwartete Fehler beim Review.

Was sind Akzeptanzkriterien?

Akzeptanzkriterien sind eine Reihe spezifischer, testbarer Bedingungen, die an eine einzelne User Story geknüpft sind. Sie legen fest, was das Feature aus der Nutzerperspektive leisten muss (und was nicht). Sobald alle Bedingungen erfüllt sind, gilt die Story als akzeptiert. Scheitert auch nur eine davon, wird weitergearbeitet.

Stellen Sie sie sich als Vertrag zwischen der Person, die das Feature angefordert hat, und dem Team vor, das es baut. Kein Raten. Kein "Ich hatte etwas anderes gemeint." Nur eine klare Liste von Bestehen-oder-Scheitern-Bedingungen, die vor Beginn der Entwicklung festgelegt wird.

Akzeptanzkriterien gelten auf Story-Ebene. Sie beantworten die Frage: "Woran erkennen wir, dass diese Story fertig ist?" Das ist eine andere Frage als "Woran erkennen wir, dass der Sprint fertig ist?" Diese beantwortet die Definition of Done.

Wichtige Fakten

• Das Given-When-Then-Format für Akzeptanzkriterien wurde von Dan North im Rahmen von Behaviour-Driven Development (BDD) um 2006 eingeführt und gibt Teams eine strukturierte, testbare Möglichkeit, erwartetes Verhalten auszudrücken. (Quelle: Dan North, "Introducing BDD," dannorth.net, 2006.)
• Die Agile Alliance stellt fest, dass unklare oder fehlende Akzeptanzkriterien zu den häufigsten Ursachen für Nacharbeit in Agile-Projekten zählen. (Quelle: Agile Alliance Glossary, agilealliance.org.)
• Teams, die Akzeptanzkriterien vor dem Coding formulieren, berichten von schnelleren Übergaben von der Entwicklung an das QA, weil Tester bereits wissen, was zu prüfen ist.

Formate für Akzeptanzkriterien

Es gibt zwei Formate, die Teams am häufigsten verwenden. Keines ist universell besser. Wählen Sie das Format, das zur Arbeitsweise Ihres Teams passt.

Given-When-Then (szenariobasiert)

Dieses Format, auch Gherkin-Format genannt, stammt aus dem Behaviour-Driven Development (BDD). Es strukturiert jede Bedingung als Szenario mit drei Teilen:

• Given (Gegeben): der Ausgangszustand oder Kontext
• When (Wenn): die Aktion, die der Nutzer ausführt
• Then (Dann): das erwartete Ergebnis

Beispiel: Benutzeranmeldung:

Given ein registrierter Benutzer befindet sich auf der Anmeldeseite
When er eine gültige E-Mail-Adresse und das richtige Passwort eingibt und auf "Anmelden" klickt
Then wird er zu seinem Dashboard weitergeleitet und sieht eine Willkommensnachricht

Given ein registrierter Benutzer befindet sich auf der Anmeldeseite
When er eine gültige E-Mail-Adresse und ein falsches Passwort eingibt
Then sieht er eine Fehlermeldung: "E-Mail oder Passwort ist falsch" und bleibt auf der Anmeldeseite

Dieses Format eignet sich gut, wenn das Verhalten sequenziell ist und Sie mehrere Fehlerfälle neben den Erfolgspfaden formulieren können. QA-Ingenieure können jedes Szenario direkt in einen Testfall umwandeln.

Regelbasiert (Checkliste)

Manche Teams bevorzugen eine einfache Liste von Regeln. Dieses Format eignet sich für Stories, bei denen die Bedingungen unabhängig voneinander und nicht sequenziell sind.

Beispiel: Produktsuche:

- Suchergebnisse erscheinen innerhalb von 2 Sekunden für jede Anfrage
- Ergebnisse sind standardmäßig nach Relevanz sortiert
- Benutzer können Ergebnisse nach Kategorie, Preisbereich und Bewertung filtern
- Wenn keine Ergebnisse gefunden werden, zeigt die Seite: "Keine Ergebnisse für [Anfrage]. Versuchen Sie andere Suchbegriffe."
- Die Suchleiste behält die Anfrage des Benutzers nach dem Laden der Ergebnisse bei

Regelbasierte Akzeptanzkriterien lassen sich schneller formulieren und einfacher überfliegen. Sie eignen sich am besten für UI-Einschränkungen, Leistungsanforderungen und Sonderfälle, die sich nicht klar einer Benutzeraktionssequenz zuordnen lassen.

Akzeptanzkriterien vs. Definition of Done

Diese beiden Konzepte werden häufig verwechselt. Sie lösen unterschiedliche Probleme.

Eine Story kann alle ihre Akzeptanzkriterien erfüllen und trotzdem an der Definition of Done scheitern, etwa wenn Unit-Tests fehlen oder kein Peer-Review stattgefunden hat. Beide Listen müssen erfüllt sein, bevor die Arbeit wirklich abgeschlossen ist.

Die vollständige Aufschlüsselung finden Sie im Artikel zur Definition of Done.

Merkmale guter Akzeptanzkriterien

Nicht jede Liste von Bedingungen erfüllt die Anforderungen an gute Akzeptanzkriterien. Hier ist, was nützliche von vagen unterscheidet:

Testbar. Jede Bedingung muss ein klares Bestehen oder Scheitern haben. "Die UI sieht gut aus" ist nicht testbar. "Der Button erfüllt ein Kontrastverhältnis von 4,5:1" hingegen schon.

Aus der Nutzerperspektive formuliert. Akzeptanzkriterien beschreiben, was der Nutzer erlebt, nicht wie der Code aufgebaut ist. Vermeiden Sie Implementierungsdetails wie "Die API gibt einen 200-Status zurück." Bevorzugen Sie: "Der Benutzer sieht sein aktualisiertes Profil sofort."

Konkret. Zahlen, Zustände und Bezeichnungen sind wichtig. "Schnelle Reaktion" wird zu "Reaktion unter 1,5 Sekunden." "Eine Fehlermeldung" wird zu "der genaue Text: 'Das Passwort muss mindestens 8 Zeichen haben.'"

Vor Beginn der Entwicklung abgestimmt. Kriterien, die nach Fertigstellung des Features formuliert werden, neigen dazu, das Gebaute zu rechtfertigen statt das Benötigte zu beschreiben. Formulieren Sie sie während des Backlog Refinement.

Nicht zu viele. Drei bis acht Bedingungen sind ein gesundes Maß. Eine Story mit fünfzehn Akzeptanzkriterien verbirgt wahrscheinlich zwei oder drei Stories in einer.

So formulieren Sie Akzeptanzkriterien

Schritt 1: Mit der User Story beginnen

Ohne eine klare User Story können Sie keine Akzeptanzkriterien formulieren. Stellen Sie sicher, dass sie in diesem Format vorliegt:

Als [Persona] möchte ich [Ziel], damit [Grund].

Ist die Story vage, schärfen Sie sie, bevor Sie Bedingungen formulieren.

Schritt 2: Fragen Sie: "Was muss wahr sein, damit dies funktioniert?"

Listen Sie die Verhaltensweisen und Ergebnisse auf, die das Feature produzieren muss. Beginnen Sie mit dem Erfolgspfad, dann die Sonderfälle und Fehlerzustände.

Schritt 3: Format wählen

Wählen Sie Given-When-Then, wenn das Verhalten sequenziell ist und das QA die Testerstellung vorantreibt. Wählen Sie regelbasiert, wenn die Bedingungen unabhängig sind oder Sie unter Zeitdruck stehen.

Schritt 4: In testbarer Sprache formulieren

Ersetzen Sie vage Formulierungen. "Schnell" wird zu einer Zahl. "Korrekt formatiert" wird zum genauen Format. "Sollte auf Mobilgeräten funktionieren" wird zu "Layout ist bei 375px Breite responsiv."

Schritt 5: Vor Beginn der Entwicklung mit dem Team reviewen

Teilen Sie den Entwurf mit Entwicklern, QA und Stakeholdern. Entwickler erkennen Bedingungen, die technisch nicht umsetzbar sind. QA entdeckt fehlende Sonderfälle. Stakeholder erkennen Fehler in der Geschäftslogik. Tun Sie dies während des Backlog Refinement oder der Sprint-Planung, damit alle vor der ersten Codezeile übereinstimmen.

Schritt 6: An die Story anhängen

Fügen Sie die finalisierten Kriterien der Story in Ihrem Product Backlog hinzu. Sie bleiben während der gesamten Entwicklung angehängt und sind die Checkliste, die Ihr Team beim Sprint Review verwendet.

Beispiele für Akzeptanzkriterien

Hier sind drei ausgearbeitete Beispiele für verschiedene Story-Typen.

Beispiel 1: Benutzeranmeldung

Story: Als wiederkehrender Benutzer möchte ich mich mit meiner E-Mail-Adresse und meinem Passwort anmelden, damit ich auf mein Konto zugreifen kann.

Given der Benutzer befindet sich auf der Anmeldeseite
When er eine registrierte E-Mail-Adresse und das richtige Passwort eingibt und auf "Anmelden" klickt
Then wird er innerhalb von 2 Sekunden zu seinem Dashboard weitergeleitet

Given der Benutzer gibt dreimal ein falsches Passwort ein
When er einen vierten Anmeldeversuch unternimmt
Then wird das Konto für 30 Minuten gesperrt und der Benutzer sieht:
"Zu viele fehlgeschlagene Versuche. Bitte versuchen Sie es in 30 Minuten erneut."

Given der Benutzer ist angemeldet
When er auf "Abmelden" klickt
Then endet seine Sitzung und er wird zur Startseite weitergeleitet

Beispiel 2: Bestellsumme

Story: Als Käufer möchte ich meine Bestellsumme sehen, bevor ich bezahle, damit ich genau weiß, was ich schulde.

Beispiel 3: Suche ohne Ergebnisse

Story: Als Benutzer möchte ich wissen, wenn meine Suche nichts ergibt, damit ich andere Suchbegriffe ausprobieren kann.

- Wenn eine Suche null Ergebnisse liefert, zeigt die Seite: "Keine Ergebnisse für '[Anfrage]'. Versuchen Sie andere Suchbegriffe."
- Die Suchleiste behält die ursprüngliche Anfrage des Benutzers bei
- Verwandte Kategorievorschläge erscheinen unterhalb der Meldung, sofern verfügbar
- Der Seitentitel aktualisiert sich, um den leeren Suchzustand widerzuspiegeln

Häufige Fehler vermeiden

Im Nachhinein formulieren. Akzeptanzkriterien, die nach der Entwicklung formuliert werden, beschreiben das Gebaute, nicht das Benötigte. Formulieren Sie sie zuerst.

Fehlerzustände vage lassen. Kriterien, die nur den Erfolgspfad abdecken, lassen Entwickler bei der Fehlerbehandlung raten. Fügen Sie immer mindestens ein Fehlerszenario hinzu.

Technische Implementierung einmischen. "Der Service ruft die Zahlungs-API mit einem POST-Request auf" ist kein Akzeptanzkriterium. "Der Benutzer sieht eine Zahlungsbestätigung innerhalb von 3 Sekunden" ist eines.

Zu groß machen. Wenn Ihre Akzeptanzkriterien mehrere verschiedene Features abdecken, teilen Sie die Story auf. Eine gute Story mit guten Kriterien passt auf eine Karteikarte.

Team-Review überspringen. Kriterien, die allein formuliert werden (meist vom Product Owner), verpassen Entwicklereinschränkungen und QA-Sonderfälle. Reviewen Sie gemeinsam, bevor der Sprint beginnt. Nutzen Sie Agile Ceremonies wie das Refinement, um dies konsequent zu tun.

Häufig gestellte Fragen

Was sind Akzeptanzkriterien?

Akzeptanzkriterien sind die spezifischen, testbaren Bedingungen, die eine User Story erfüllen muss, bevor das Team sie als abgeschlossen akzeptiert. Sie legen fest, was das Feature aus der Nutzerperspektive leisten muss, und werden vor Beginn der Entwicklung formuliert.

Wer formuliert Akzeptanzkriterien?

Der Product Owner entwirft die Akzeptanzkriterien in der Regel, aber das gesamte Team, also Entwickler, QA und manchmal Stakeholder, reviewt und verfeinert sie, bevor die Entwicklung beginnt. Das alleinige Formulieren führt zu übersehenen Sonderfällen und Nacharbeit.

Was ist der Unterschied zwischen Akzeptanzkriterien und der Definition of Done?

Akzeptanzkriterien sind pro Story: Sie beschreiben, was ein bestimmtes Feature leisten muss. Die Definition of Done ist global: Sie ist eine Checkliste, die für jede Story im Sprint gilt (Peer-Review, Testabdeckung, Dokumentation usw.). Eine Story muss beides erfüllen, bevor sie geliefert wird.

Was ist Given-When-Then?

Given-When-Then ist ein strukturiertes Format zum Formulieren von Akzeptanzkriterien als testbare Szenarien. "Given" setzt den Kontext, "When" beschreibt die Aktion des Benutzers und "Then" gibt das erwartete Ergebnis an. Es wurde von Dan North im Rahmen von Behaviour-Driven Development (BDD) um 2006 eingeführt und wird heute in Agile-Teams weit verbreitet eingesetzt.

Wie viele Akzeptanzkriterien sollte eine User Story haben?

Streben Sie drei bis acht an. Weniger als drei bedeutet oft, dass die Story zu wenig spezifiziert ist. Mehr als acht bedeutet in der Regel, dass die Story zu groß ist und in kleinere Stories aufgeteilt werden sollte.

---

Gute Akzeptanzkriterien garantieren kein großartiges Produkt, aber sie verhindern eine spezifische Kategorie von Fehlern: etwas zu bauen, das niemand so gemeint hat. Formulieren Sie sie frühzeitig, reviewen Sie sie gemeinsam, und Ihre Sprint Reviews werden sich von Debatten darüber, was "fertig" bedeutet, zu unkomplizierten Demonstrationen funktionierender Software wandeln.