Akzeptanzkriterien: Der komplette Guide mit Beispielen
“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:
| Aspekt | Akzeptanzkriterien | Definition of Done |
|---|---|---|
| Bezieht sich auf | Eine einzelne Story | Alle Stories im Team |
| Inhalt | Fachliche Anforderungen | Qualitätsstandards |
| Wer definiert | Product Owner | Team + PO |
| Beispiel | “E-Mail kommt in 2 Min.” | “Code ist reviewed” |
| Kann variieren | Ja, pro Story anders | Nein, 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:
- PO schreibt erste Kriterien
- Team stellt Fragen im Refinement
- Gemeinsam werden Kriterien verfeinert
- Entwickler identifizieren fehlende Edge Cases
- 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?
Spezifisch
Sind alle relevanten Details genannt?
Unabhängig
Kann das Kriterium für sich allein geprüft werden?
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?
Häufige Fehler bei Akzeptanzkriterien
1. Zu vage
2. Technische Implementation beschrieben
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.
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