Akzeptanzkriterien richtig schreiben

Akzeptanzkriterien richtig schreiben – Akzeptanzkriterien entscheiden, ob ein Ergebnis „fertig“ ist – oder nur so aussieht. Trotzdem entstehen sie in vielen Projekten nebenbei, unscharf formuliert, oft zu spät. Die Folge: Endlose Diskussionen, Rework, unzufriedene Stakeholder und Teams, die aneinander vorbeiarbeiten.

In diesem Leitfaden erfahren Sie praxisnah, wie Sie Akzeptanzkriterien so schreiben, dass alle Beteiligten dasselbe Bild vor Augen haben – von der User Story im agilen Projekt bis zur klassischen Anforderung. Mit klaren Beispielen, Vorlagen und Formulierungsmustern, die Sie direkt übernehmen können.

Akzeptanzkriterien sind klare, überprüfbare Bedingungen, die festlegen, wann eine Anforderung (z. B. eine User Story, ein Feature oder ein Arbeitspaket) als erfüllt gilt.

Kurz gesagt:
Eine Anforderung ist dann erledigt, wenn alle definierten Akzeptanzkriterien erfüllt sind.

Typische Merkmale:

Gut geschriebene Akzeptanzkriterien:

Fehlen sie oder sind sie schwammig, passiert in der Praxis oft Folgendes:

Akzeptanzkriterien sind deshalb kein Formalismus, sondern Risikomanagement.

Akzeptanzkriterien sind sinnvoll für:

Idealer Zeitpunkt:

Diese Muster begegnen in nahezu jedem Projekt:

Gut geschriebene Akzeptanzkriterien sind:

Hilfreiche Daumenregel:
Wenn zwei Personen das Kriterium unterschiedlich interpretieren können, ist es noch nicht gut genug.

Oft herrscht Verwirrung zwischen Akzeptanzkriterien und „Definition of Done“ (DoD).

Merksatz:
Akzeptanzkriterien prüfen „Was“ geliefert wurde.
Die Definition of Done prüft „Wie“ geliefert wurde.

Beide ergänzen sich, sie ersetzen einander nicht.

Für viele Business-Anforderungen völlig ausreichend.

Beispiel:

Vorteile:

Strukturiertes Format aus dem Behavior-Driven Development (BDD). Eignet sich, wenn Sie:

Struktur:

Beispiel:

Hilfreich bei vielen Varianten (z. B. unterschiedliche Rollen, Status, Berechtigungen).

Beispiel (verkürzt):

Bevor Sie ein einziges Akzeptanzkriterium formulieren, beantworten Sie drei Fragen:

Beispiel-User-Story:
„Als registrierter Kunde möchte ich mich mit E-Mail und Passwort einloggen können, damit ich Zugriff auf meine Aufträge habe.“

Überlegen Sie mit Fachbereich, Product Owner und ggf. QA:

Nutzen Sie Fragen wie:

Formulieren Sie jedes Szenario als überprüfbares Kriterium:

Beispiel (Login):

Bleiben Sie in einem Kontext konsistent. Mischen Sie nicht zu viele Formate in einer User Story.

Gehen Sie jedes Kriterium durch:

Streichen oder überarbeiten Sie alles, was:

Akzeptanzkriterien sind kein Monolog eines Einzelnen, sondern Ergebnis einer gemeinsamen Verständigung. Binden Sie ein:

Regel:
Änderungen an Anforderung → Akzeptanzkriterien mitanpassen.
Sonst laufen Sie mit veralteten Kriterien weiter.

Schlecht:

Probleme: vage, nicht messbar, rein qualitativ.

Gut (Bullet-Format):

Schlecht:

Gut (Given-When-Then):

In der Praxis bewährt sich:

Spätestens, wenn eine User Story / Anforderung in die Umsetzung geht. Besser bereits beim Refinement, um:

So viele wie nötig, so wenige wie möglich. Hinweise:

Aus guten Akzeptanzkriterien lassen sich Testfälle direkt ableiten.

Nutzen Sie diese Liste vor der Freigabe einer User Story oder Anforderung:

User Story
„Als [Rolle] möchte ich [Funktion], damit ich [Nutzen].“

Akzeptanzkriterien (Beispielstruktur):

Alternative: Given-When-Then

Mehrere Szenarien können als getrennte Blöcke formuliert werden.

Akzeptanzkriterien „richtig schreiben“ ist mehr als eine Schreibübung. Es ist eine Führungsaufgabe:

Wenn Sie Akzeptanzkriterien konsequent nutzen:

Wenn Sie möchten, dass Ihre Projekte hiervon systematisch profitieren, lohnt sich ein strukturierter Blick auf Ihre bisherige Praxis – von der Formulierung der Anforderungen bis zur Abnahme. Eine externe Perspektive hilft, blinde Flecken zu identifizieren und praxistaugliche Standards zu etablieren.