agilemind.consulting
Alle Artikel

Akzeptanzkriterien: Der komplette Guide mit Beispielen

| Robert Giacinto | 6 Min. Lesezeit | 1222 Wörter

“Ist die Story fertig?” — Diese Frage führt in vielen Teams zu Diskussionen. Akzeptanzkriterien beenden diese Diskussion, bevor sie beginnt. Sie definieren objektiv und testbar, wann eine User Story als erledigt gilt.

In diesem Guide zeige ich dir, wie du Akzeptanzkriterien schreibst, die dein Team versteht und die Tester lieben.

Was sind Akzeptanzkriterien?

Akzeptanzkriterien sind Bedingungen, die erfüllt sein müssen, damit eine User Story als abgeschlossen gilt. Sie beantworten die Frage: “Woran erkennen wir, dass diese Story richtig umgesetzt wurde?”

Beispiel User Story:

Als Kunde möchte ich mein Passwort zurücksetzen, damit ich wieder auf mein Konto zugreifen kann.

Akzeptanzkriterien:

  • Nutzer erhält E-Mail mit Reset-Link innerhalb von 2 Minuten
  • Link ist 24 Stunden gültig
  • Neues Passwort muss mindestens 8 Zeichen haben
  • Nach erfolgreichem Reset wird Nutzer automatisch eingeloggt
  • Ungültige oder abgelaufene Links zeigen verständliche Fehlermeldung

Akzeptanzkriterien vs. Definition of Done

Diese beiden Konzepte werden oft verwechselt:

AspektAkzeptanzkriterienDefinition of Done
Bezieht sich aufEine einzelne StoryAlle Stories im Team
InhaltFachliche AnforderungenQualitätsstandards
Wer definiertProduct OwnerTeam + PO
Beispiel“E-Mail kommt in 2 Min.”“Code ist reviewed”
Kann variierenJa, pro Story andersNein, für alle gleich

Definition of Done (DoD) sind teamweite Standards wie:

  • Code Review durchgeführt
  • Unit Tests geschrieben
  • Dokumentation aktualisiert
  • Keine kritischen Bugs

Akzeptanzkriterien sind story-spezifische Anforderungen wie:

  • Benutzer kann sich mit E-Mail einloggen
  • Fehlermeldung erscheint bei falschem Passwort

Eine Story ist erst “Done”, wenn beide erfüllt sind: Die Akzeptanzkriterien der Story und die Definition of Done des Teams.

Das Given-When-Then Format

Das strukturierteste Format für Akzeptanzkriterien ist Given-When-Then (auch Gherkin genannt):

Given: [Ausgangszustand / Voraussetzung]
When: [Aktion / Ereignis]
Then: [Erwartetes Ergebnis]

Warum dieses Format?

  • Klar strukturiert: Jeder versteht den Aufbau
  • Testbar: Direkt in automatisierte Tests überführbar
  • Vollständig: Zwingt, Kontext zu definieren

Beispiele im Given-When-Then Format

E-Commerce: Warenkorb

Given: Ich habe 3 Produkte im Warenkorb
When: Ich eines davon entferne
Then: Zeigt der Warenkorb 2 Produkte
And: Die Summe wird korrekt aktualisiert

SaaS: Login

Given: Ich bin auf der Login-Seite
When: Ich E-Mail und falsches Passwort eingebe
Then: Erscheint die Meldung "E-Mail oder Passwort falsch"
And: Das Passwort-Feld wird geleert
And: Ich bleibe auf der Login-Seite

Mobile App: Push-Benachrichtigung

Given: Ich habe Push-Benachrichtigungen aktiviert
When: Eine neue Nachricht eintrifft
Then: Erhalte ich eine Push-Notification
And: Die Notification zeigt Absender und Vorschau

Wer definiert Akzeptanzkriterien?

Primär verantwortlich: Product Owner

Beteiligt: Das gesamte Team im Refinement

Der Product Owner bringt die fachlichen Anforderungen ein. Im Refinement ergänzt das Team:

  • Technische Randbedingungen
  • Edge Cases
  • Performance-Anforderungen
  • Fehlerfälle

Typischer Ablauf:

  1. PO schreibt erste Kriterien
  2. Team stellt Fragen im Refinement
  3. Gemeinsam werden Kriterien verfeinert
  4. Entwickler identifizieren fehlende Edge Cases
  5. Finale Kriterien werden dokumentiert

15 Akzeptanzkriterien-Beispiele nach Branche

E-Commerce (5 Beispiele)

1. Produktsuche

Given: Ich bin auf der Startseite
When: Ich "Sneaker" in die Suche eingebe
Then: Zeigt die Ergebnisliste alle Produkte mit "Sneaker" im Namen
And: Ergebnisse sind nach Relevanz sortiert
And: Jedes Ergebnis zeigt Bild, Name und Preis

2. Checkout-Prozess

Given: Ich habe Produkte im Warenkorb
When: Ich zur Kasse gehe
Then: Sehe ich eine Zusammenfassung aller Produkte
And: Versandkosten werden basierend auf PLZ berechnet
And: Ich kann Gutscheincode eingeben

3. Bestellbestätigung

Given: Ich habe eine Bestellung abgeschlossen
When: Die Zahlung erfolgreich war
Then: Erhalte ich eine Bestätigungs-E-Mail innerhalb von 5 Minuten
And: Die E-Mail enthält Bestellnummer, Produkte und Lieferadresse

4. Produktbewertung

Given: Ich bin eingeloggt und habe das Produkt gekauft
When: Ich eine Bewertung abgebe
Then: Wird meine Bewertung nach Moderation angezeigt
And: Der Durchschnittsscore wird aktualisiert

5. Wunschliste

Given: Ich bin eingeloggt
When: Ich auf das Herz-Icon eines Produkts klicke
Then: Wird das Produkt meiner Wunschliste hinzugefügt
And: Das Icon ändert sich zu "ausgefüllt"
And: Die Wunschlisten-Zahl im Header erhöht sich

SaaS / Software (5 Beispiele)

6. Benutzerregistrierung

Given: Ich bin auf der Registrierungsseite
When: Ich alle Pflichtfelder ausfülle und absende
Then: Wird mein Account erstellt
And: Ich erhalte eine Bestätigungs-E-Mail
And: Ich werde zur Onboarding-Seite weitergeleitet

7. Dashboard-Filter

Given: Ich bin im Analytics-Dashboard
When: Ich den Datumsfilter auf "Letzte 7 Tage" setze
Then: Zeigen alle Grafiken Daten der letzten 7 Tage
And: Die URL enthält den Filter-Parameter
And: Der Filter bleibt bei Seitenwechsel erhalten

8. Team-Einladung

Given: Ich bin Admin eines Workspaces
When: Ich eine E-Mail-Adresse zur Einladung eingebe
Then: Erhält die Person eine Einladungs-E-Mail
And: Die Person erscheint als "Eingeladen" in der Mitgliederliste
And: Nach Annahme wechselt Status zu "Aktiv"

9. Export-Funktion

Given: Ich habe Daten in einer Tabelle
When: Ich auf "Export CSV" klicke
Then: Wird eine CSV-Datei heruntergeladen
And: Die Datei enthält alle sichtbaren Spalten
And: Der Dateiname enthält Datum und Tabellenname

10. Zwei-Faktor-Authentifizierung

Given: 2FA ist für meinen Account aktiviert
When: Ich mich mit E-Mail und Passwort einlogge
Then: Werde ich nach dem 2FA-Code gefragt
And: Nach korrektem Code bin ich eingeloggt
And: Bei falschem Code bleibe ich auf der 2FA-Seite

Mobile App (5 Beispiele)

11. Offline-Modus

Given: Ich bin offline
When: Ich die App öffne
Then: Werden gecachte Daten angezeigt
And: Ein Banner zeigt "Offline-Modus"
And: Änderungen werden lokal gespeichert
When: Ich wieder online bin
Then: Werden lokale Änderungen synchronisiert

12. Bildupload

Given: Ich bin im Profil-Bereich
When: Ich auf "Foto ändern" tippe
Then: Kann ich Kamera oder Galerie wählen
And: Das Bild wird auf max. 1MB komprimiert
And: Ich sehe eine Vorschau vor dem Speichern

13. Pull-to-Refresh

Given: Ich bin in der Artikelliste
When: Ich nach unten ziehe
Then: Erscheint ein Lade-Indikator
And: Die Liste wird aktualisiert
And: Neue Artikel erscheinen oben

14. Deep Link

Given: Ich erhalte einen Link zu einem Artikel
When: Ich den Link antippe
Then: Öffnet sich die App (falls installiert)
And: Ich lande direkt beim Artikel
And: Der Zurück-Button führt zur Übersicht

15. Lokale Benachrichtigungen

Given: Ich habe einen Reminder erstellt
When: Die eingestellte Zeit erreicht ist
Then: Erhalte ich eine lokale Benachrichtigung
And: Tippen auf die Benachrichtigung öffnet den Reminder
And: Die Benachrichtigung verschwindet nach Bestätigung

Checkliste für gute Akzeptanzkriterien

Testbar

Kann ein Tester (oder automatisierter Test) prüfen, ob das Kriterium erfüllt ist?

Schlecht
“Das System soll benutzerfreundlich sein”
Gut
“Der Nutzer findet den Warenkorb in max. 2 Klicks”

Spezifisch

Sind alle relevanten Details genannt?

Schlecht
“E-Mail wird schnell gesendet”
Gut
“E-Mail wird innerhalb von 2 Minuten zugestellt”

Unabhängig

Kann das Kriterium für sich allein geprüft werden?

Schlecht
“Funktioniert wie im letzten Sprint besprochen”
Gut
Alle Bedingungen sind im Kriterium selbst dokumentiert

Vollständig

Sind alle wichtigen Szenarien abgedeckt?

  • Happy Path (alles funktioniert)
  • Fehlerfälle (was bei Problemen passiert)
  • Edge Cases (Grenzfälle wie leere Listen, lange Texte)

Verständlich

Versteht jeder im Team das Kriterium gleich?

Schlecht
“Das Backend verarbeitet die Request korrekt”
Gut
“Nach Klick auf Speichern erscheint Erfolgsmeldung”

Häufige Fehler bei Akzeptanzkriterien

1. Zu vage

Schlecht
“Die Seite lädt schnell”
Gut
“Die Seite lädt in unter 2 Sekunden bei 3G”

2. Technische Implementation beschrieben

Schlecht
“Die API gibt JSON mit Status 200 zurück”
Gut
“Der Nutzer sieht eine Erfolgsmeldung”

3. Zu viele Kriterien

Wenn eine Story 15+ Kriterien hat, ist sie wahrscheinlich zu groß. Aufteilen!

4. Fehlende Fehlerfälle

Was passiert bei:

  • Ungültiger Eingabe?
  • Timeout?
  • Fehlenden Berechtigungen?

5. Copy-Paste ohne Anpassung

Jede Story braucht eigene, passende Kriterien — nicht generische Vorlagen.


Akzeptanzkriterien sind der Vertrag zwischen Product Owner und Team. Je klarer sie sind, desto weniger Diskussionen gibt es am Ende des Sprints.

Der Aufwand, gute Kriterien zu schreiben, zahlt sich mehrfach aus: Weniger Nacharbeit, bessere Tests, zufriedenere Stakeholder. Wenn dein Team Schwierigkeiten hat, klare Kriterien zu formulieren, kann ein erfahrener Product Owner Coach den Prozess verbessern.

Product Owner Coaching

Klare Akzeptanzkriterien, weniger Missverständnisse

Im Coaching verbessern wir gemeinsam eure User Stories — von vagen Anforderungen zu testbaren Kriterien.

  • Eindeutige Definition von 'fertig'
  • Weniger Nacharbeit nach dem Sprint
  • Bessere Zusammenarbeit PO-Team

Ab 400 € · Remote oder vor Ort