User Stories liegen in grobgranularer Form vor (Titel, Beschreibung, Nutzerwert), sind aber noch nicht implementierungsreif.
Acceptance Criteria Workshop
Vorbedingung
Was vorher fertig sein muss
Vorbereitung
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit Spalten pro Story; Story-Karten oder Tickets sichtbar; Given-When-Then-Vorlage als Banner; Stifte; Timer; Definition of Done als Referenz.
Ein Facilitator (PO, Scrum Master oder BA); Product Owner für Scope; mindestens ein Engineer; ein Tester für Edge Cases; optional Domain-Experte bei fachlicher Tiefe.
Story-Beschreibungen mit Nutzerwert; bekannte Constraints (Performance, Compliance, Browser-Support); Definition of Done; ähnliche bestehende Stories als Referenz.
20-40 min pro Story
Pro Story eine Sektion im Board. Given-When-Then-Template sichtbar. Definition of Done als Sidebar. Regel: keine vagen Kriterien (schnell, einfach, schön). Konkrete, prüfbare Aussagen.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welche konkreten, prüfbaren Kriterien beschreiben Happy-Path, Edge Cases und negative Pfade dieser Story so eindeutig, dass alle drei Rollen Definition of Done teilen?
Ablauf
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Story-Kurzbeschreibung fixieren | 3-5 min | Story als Titel und Nutzerwert-Satz an Wand. Klärungsfragen zu Scope. PO bestätigt Verständnis. | Wenn nach 5 min Scope unklar, Story zurück in Discovery. Akzeptanzkriterien ohne Scope-Konsens sind nutzlos. |
2Phase 2: Happy-Path-Kriterien | 5-10 min | Given-When-Then für den Standardfall. Konkrete Eingabewerte, beobachtbare Ausgabe. Mindestens 2-3 Kriterien pro Story. | Vage Kriterien wie „funktioniert“ oder „intuitiv“ ablehnen. Pro Kriterium muss Test-Frage möglich sein: „Wie würde ich das prüfen?“ |
3Phase 3: Edge Cases und Sonderfälle | 5-15 min | Tester treibt Edge-Case-Suche: Nullwerte, Max-Werte, leere Eingaben, parallele Aktionen. Pro Edge Case eigenes Kriterium. | Wenn keine Edge Cases entstehen, Story zu oberflächlich verstanden. Mindestens 30% der Kriterien sollten Edge Cases abdecken. |
4Phase 4: Negative Pfade und Fehlerfälle | 5-10 min | Was passiert bei ungültiger Eingabe, fehlender Berechtigung, externem Fehler. Erwartete Fehlermeldung oder System-Reaktion als Kriterium. | Negative Pfade werden oft vergessen. PO entscheidet, ob Fehlerfall in Story oder als eigene Story. Beide Optionen valide, aber bewusst. |
5Phase 5: Review und Übernahme | 3-5 min | Kriterien laut vorlesen. Engineer und Tester bestätigen Umsetzbarkeit/Prüfbarkeit. Kriterien ins Story-Werkzeug übertragen. | Vorlesen deckt Unklarheiten auf. Bei Widerspruch zwischen Rollen sofort klären, nicht in Sprint mitnehmen. |
Artefakt
Was am Ende rauskommt
Akzeptanzkriterien im Story-Werkzeug (Jira, Linear, GitHub) im Given-When-Then-Format oder als Bullet-Liste. Pro Story 4-10 Kriterien typisch. Edge Cases gekennzeichnet. Verlinkt mit Definition of Done.
- Jira mit Story-Description-Feld
- Linear mit Issue-Body
- GitHub Issues mit Markdown-Checkboxen
- Azure DevOps mit Acceptance-Criteria-Feld
- Notion-Datenbank mit Property-Feld
Kriterien als Teil der Story versioniert. Bei Änderung nach Sprint-Start Begründung im Story-Kommentar. Kriterien-Templates pro Domäne im Wiki, alle 3-6 Monate prüfen.
Acceptance Criteria Workshop Arbeitsvorlage
Kompakte Arbeitsvorlage für Acceptance Criteria Workshop mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Acceptance Criteria Workshop Checklist
- [ ] Ziel und Kontext geklärt
- [ ] Input-Material gesammelt
- [ ] Beteiligte und Rollen benannt
- [ ] Durchführung nach Run Sheet vorbereitet
- [ ] Ergebnisartefakte erstellt
- [ ] Acceptance Criteria aktualisiert
- [ ] Story-Update aktualisiert
- [ ] Offene Fragen dokumentiert
- [ ] Nächster Schritt mit Owner und Datum gesetztBeispielausgabe
Konkret gefülltes Szenario
## Acceptance Criteria - Story „Mandanten-Export als CSV“, 2026-05-18
**Story**: Als Steuerberater möchte ich meine Mandantenliste als CSV exportieren können, damit ich sie in DATEV importieren kann.
**Akzeptanzkriterien (Given-When-Then)**
**Happy Path**
1. Given Sabine ist eingeloggt und hat 47 Mandanten, when sie auf „Export CSV“ klickt, then wird eine Datei „mandanten_2026-05-18.csv“ mit allen 47 Zeilen heruntergeladen.
2. Given der Export läuft, when die Datei generiert wird, then enthält sie folgende Spalten: ID, Name, Steuernummer, Adresse, Status, Anlagedatum.
3. Given Sabine öffnet die CSV in Excel, when Excel UTF-8 erkennt, then werden Umlaute korrekt dargestellt (z. B. „Müller GmbH“).
**Edge Cases**
4. Given Sabine hat 0 Mandanten, when sie auf „Export CSV“ klickt, then wird eine CSV nur mit Header-Zeile heruntergeladen und eine Info-Toast erscheint „Keine Mandanten exportiert“.
5. Given Sabine hat >10.000 Mandanten, when sie auf „Export CSV“ klickt, then startet der Export asynchron und sie erhält eine E-Mail mit Download-Link innerhalb von 10 min.
6. Given Mandantennamen enthalten Komma oder Anführungszeichen, when CSV generiert wird, then werden Felder korrekt escaped nach RFC 4180.
**Negative Pfade**
7. Given Sabine hat keine „Mandanten verwalten“-Berechtigung, when sie auf „Export CSV“ klickt, then wird der Button nicht angezeigt.
8. Given das Backend ist nicht erreichbar, when Sabine auf „Export CSV“ klickt, then erscheint Fehlermeldung „Export aktuell nicht möglich, bitte später erneut versuchen“ ohne Browser-Crash.Stolperfallen
Symptome erkennen, gegensteuern
Vage Kriterien
Kriterien wie „funktioniert reibungslos“, „benutzerfreundlich“, „schnell genug“ landen in der Story.
Konkretisieren: „funktioniert“ -> „lädt in <2 s“; „benutzerfreundlich“ -> „Aufgabe in <3 Klicks“. Wer nicht konkret werden kann, hat Anforderung nicht verstanden.
Nur Happy-Path
Alle Kriterien decken Standardfall ab, Edge Cases und negative Pfade fehlen.
Faustregel: mindestens 30% Edge Cases. Tester treibt aktiv. Checkliste für typische Edge-Patterns (Null, Max, Leer, Berechtigung, Fehler) als Trigger.
Tester fehlt im Workshop
Nur PO und Engineer arbeiten an Kriterien, Edge Cases bleiben dünn.
Three-Amigos-Prinzip. Wenn Tester nicht verfügbar, Workshop verschieben oder asynchron Tester-Review einbauen vor Sprint-Start.
Kriterien ändern sich im Sprint
PO ergänzt Kriterien nach Sprint-Start, Engineer fühlt sich überfordert oder hintergangen.
Kriterien-Änderung nach Sprint-Start = Scope-Änderung. Entweder Item out of Sprint oder Erweiterung als neue Story. Klare Regel kommunizieren.
Definition of Done ignoriert
Kriterien decken Story-Logik, aber querliegende Anforderungen (Tests, Doku, Accessibility) fehlen.
Definition of Done als Sidebar im Workshop sichtbar. Pro Story prüfen: DoD-Punkte ergänzt? Generelle DoD-Punkte nicht pro Story wiederholen, aber relevante markieren.
Abbruchkriterien
Done-Signale, in unter einer Minute prüfbar
Run Sheet durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.