Akzeptanzkriterien (Acceptance Criteria)

Von nanologika | 29. Januar 2026 |

Kurzdefinition

Akzeptanzkriterien sind Kriterien/Erfüllungsbedingungen, die ein Arbeitsergebnis (z. B. User Story, Feature, Prozessschritt) erfüllen muss, damit es von den Stakeholdern akzeptiert/abgenommen wird.
In gängigen Standards werden sie auch als „Exit Criteria“ beschrieben, die ein System/Produkt erfüllen muss, um durch Nutzer:in/Kund:in oder eine autorisierte Instanz akzeptiert zu werden.

Zweck / Warum sind Akzeptanzkriterien wichtig?

Sie machen Anforderungen prüfbar und reduzieren Interpretationsspielräume („Was genau heißt fertig?“).
Sie verbinden Produktvision und Umsetzung, weil sie Erwartungen in eine Form bringen, die sich testen (manuell/automatisiert) lässt.
In agilen Teams unterstützen sie die gemeinsame Verständigung zwischen Fachseite, Entwicklung und QA – insbesondere, wenn sie als Beispiele formuliert sind (BDD/Given‑When‑Then).

Merkmale guter Akzeptanzkriterien

Gute Akzeptanzkriterien sind typischerweise:

Eindeutig (keine „schnell“, „intuitiv“, „schön“ ohne messbare Definition).
Testbar/Beobachtbar (klarer erwarteter Output/Status/Verhalten).
Fachlich formuliert (was das System tun soll – nicht wie es implementiert wird).
Vollständig genug, um Abnahme zu ermöglichen, aber nicht überladen (fokussiert auf das Verhalten/Outcome).

Häufige Formate (mit Beispielen)

1) Given–When–Then (BDD/Gherkin)

Das Given‑When‑Then‑Format ist ein verbreiteter Weg, Akzeptanzkriterien als konkrete Verhaltensbeispiele zu formulieren.
Dabei beschreibt Given den Kontext, When die Aktion/den Trigger und Then das erwartete Ergebnis.

Beispiel (Angebots-/Produktkonfigurator):

Scenario: Regelkonforme Konfiguration erzeugt ein Angebot
  Given ein Nutzer konfiguriert ein Produkt mit Optionen
  When alle gewählten Optionen gemäß Regelwerk kombinierbar sind
  Then wird ein gültiges Angebot erzeugt
  And der Gesamtpreis ist berechnet
  And die Konfiguration ist als "fertig" markiert

Dieses Format ist besonders hilfreich, weil es Anforderungen nahe an testbarer Sprache ausdrückt.

2) Checklisten-/Regelformat („Muss/Soll“-Kriterien)

Akzeptanzkriterien können auch als kurze, testbare Punkte formuliert werden („Erfüllt, wenn …“).

Beispiel (Camunda‑Prozess / Workflow):

Der Prozess endet nach erfolgreicher Freigabe im Status APPROVED.
Wenn die Bearbeitungsfrist abläuft, wird der Eskalationspfad ausgelöst und der Vorgang entsprechend markiert.

Abgrenzung: Akzeptanzkriterien vs. Definition of Done (DoD)

Akzeptanzkriterien beschreiben, welches fachliche Verhalten/Outcome geliefert werden muss, damit ein konkretes Item (Story/Feature) akzeptiert wird.
Eine Definition of Done (falls ihr sie nutzt) beschreibt dagegen meist teamweite Qualitäts- und Prozessstandards (z. B. Code Review, Tests grün, Doku aktualisiert), die für alle Items gelten. (Begriffserklärung hier als gängige agile Praxis; nicht normativ.)

Typische Stolperfallen

Zu vage Kriterien („performant“, „userfreundlich“) ohne messbare Schwellenwerte oder beobachtbares Ergebnis.
Implementierungsdetails statt Verhalten (z. B. UI‑Klickpfade als Kriterium, obwohl es um fachliches Ergebnis geht).
Zu viele Themen in einem Kriterienset (schwer zu testen und schwer zuzuordnen).

Best Practices

Schreibe Akzeptanzkriterien als Beispiele („Wenn X, dann Y“) – das erhöht Verständlichkeit und Testbarkeit.
Formuliere Outcomes messbar (z. B. „Antwortzeit < 2s“, „Status = APPROVED“).
Nutze Given–When–Then, wenn mehrere Rollen (PO/BA/Dev/QA) an einem gemeinsamen Verständnis arbeiten.