methodatlas
Run SheetAgileStory Refinement

Acceptance Criteria Workshop

KomplexitätLow
Zeit20-40 min pro Story
Teilnehmende3-6
FormatWorkshop
MaturityEstablished
01

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenStory Refinementnicht im Katalog

User Stories liegen in grobgranularer Form vor (Titel, Beschreibung, Nutzerwert), sind aber noch nicht implementierungsreif.

Ohne: Ohne Story-Vorlage entsteht Workshop ohne Bezug, Akzeptanzkriterien werden für Stoßrichtungen statt für Lieferinhalte definiert.
02

Vorbereitung

Was vor Start vorliegen muss

Materialien

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.

Personen / Rollen

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.

Vorabinfos

Story-Beschreibungen mit Nutzerwert; bekannte Constraints (Performance, Compliance, Browser-Support); Definition of Done; ähnliche bestehende Stories als Referenz.

Zeitbedarf

20-40 min pro Story

Setup

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.

03

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?

04

Ablauf

Marker: Phase

SchrittDauerAktionHinweis
1Phase 1: Story-Kurzbeschreibung fixieren
3-5 minStory 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 minGiven-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 minTester 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 minWas 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 minKriterien 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.
05

Artefakt

Was am Ende rauskommt

Form

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.

Tool-Alternativen
  • 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
Versionierung / Ownership

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.

checklist

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 gesetzt
06

Beispielausgabe

Konkret gefülltes Szenario

acceptance-criteria-workshop-beispiel.md
markdown
## 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.
07

Stolperfallen

Symptome erkennen, gegensteuern

Falle

Vage Kriterien

Symptom

Kriterien wie „funktioniert reibungslos“, „benutzerfreundlich“, „schnell genug“ landen in der Story.

Was tun

Konkretisieren: „funktioniert“ -> „lädt in <2 s“; „benutzerfreundlich“ -> „Aufgabe in <3 Klicks“. Wer nicht konkret werden kann, hat Anforderung nicht verstanden.

Falle

Nur Happy-Path

Symptom

Alle Kriterien decken Standardfall ab, Edge Cases und negative Pfade fehlen.

Was tun

Faustregel: mindestens 30% Edge Cases. Tester treibt aktiv. Checkliste für typische Edge-Patterns (Null, Max, Leer, Berechtigung, Fehler) als Trigger.

Falle

Tester fehlt im Workshop

Symptom

Nur PO und Engineer arbeiten an Kriterien, Edge Cases bleiben dünn.

Was tun

Three-Amigos-Prinzip. Wenn Tester nicht verfügbar, Workshop verschieben oder asynchron Tester-Review einbauen vor Sprint-Start.

Falle

Kriterien ändern sich im Sprint

Symptom

PO ergänzt Kriterien nach Sprint-Start, Engineer fühlt sich überfordert oder hintergangen.

Was tun

Kriterien-Änderung nach Sprint-Start = Scope-Änderung. Entweder Item out of Sprint oder Erweiterung als neue Story. Klare Regel kommunizieren.

Falle

Definition of Done ignoriert

Symptom

Kriterien decken Story-Logik, aber querliegende Anforderungen (Tests, Doku, Accessibility) fehlen.

Was tun

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.

08

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Story-Beschreibung ist zu vage, Scope kann nicht in 5 min geklärt werden.
PO nicht verfügbar, Scope-Fragen können nicht beantwortet werden.
Tester und Engineer fehlen, Edge Cases und Machbarkeit bleiben unklar.
Story ist sehr klein und trivial (1-2 Kriterien reichen), Workshop wäre Overhead.
Definition of Done existiert nicht, Workshop hätte keinen Referenzrahmen.
Team kennt Given-When-Then-Notation nicht, Lernkurve nicht im Refinement-Zeitfenster leistbar.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.