Akzeptanzkriterien im Scrum

Akzeptanzkriterien im Scrum – Akzeptanzkriterien im Scrum entscheiden, ob eine User Story wirklich fertig ist – oder ob später teure Nacharbeiten, Missverständnisse und Frust entstehen. In vielen Teams sind sie jedoch unscharf formuliert, werden zu spät gedacht oder als „Formalität“ behandelt.

In diesem Beitrag erfahren Sie, wie Sie klare Akzeptanzkriterien definieren, welche Qualitätsmaßstäbe sich bewährt haben, welche Fehler Sie vermeiden sollten und wie Sie Ihr Team Schritt für Schritt zu besseren Kriterien führen. Mit konkreten Beispielen, Vorlagen und Formulierungsbausteinen, die Sie direkt im nächsten Refinement nutzen können.

Akzeptanzkriterien sind fachliche Bedingungen, die erfüllt sein müssen, damit eine User Story oder ein Product Backlog Item als erledigt und akzeptiert gilt.

Sie beschreiben:

Wichtig:

Hier gehen viele Teams durcheinander. Die saubere Trennung verhindert Diskussionen am Ende des Sprints.

Akzeptanzkriterien

Definition of Done (DoD)

Merksatz:
DoD = generelle Qualitätslatte des Teams.
Akzeptanzkriterien = fachliche Erwartung der Stakeholder an diese konkrete Story.

Beides braucht es. Eine Story kann alle Akzeptanzkriterien erfüllen und trotzdem nicht „Done“ sein (z. B. noch nicht deployt). Umgekehrt kann sie DoD-konform umgesetzt sein, aber fachlich an den Erwartungen vorbeigehen, wenn Akzeptanzkriterien fehlen oder unklar sind.

Gut formulierte Akzeptanzkriterien sind kein Selbstzweck. Sie erfüllen im Scrum-Kontext mehrere Funktionen:

Verantwortlich:

Zeitpunkt:

Praxisregel:

Akzeptanzkriterien sind dann gut, wenn sie:

Hilfreiche Leitfragen:

Die INVEST-Regel ist ein verbreitetes Qualitätsraster für User Stories. Sie hilft indirekt auch bei der Qualität der Akzeptanzkriterien.

INVEST steht für:

Gerade das „T“ ist zentral:

In der Praxis haben sich zwei Formate besonders bewährt:

Einfach, direkt, gut für den Einstieg.

Beispiel für eine Story „Als registrierter Nutzer möchte ich mein Passwort zurücksetzen“:

Akzeptanzkriterien:

Vorteile:

Strukturierte Beschreibung von Szenarien. Ideal für Teams, die viel testen oder BDD (Behavior Driven Development) nutzen.

Aufbau:

Beispiel (gleiche Story):

Vorteile:

Viele Teams kombinieren beides: kurze Bullets für Überblick, konkrete Given-When-Then-Szenarien für kritische Fälle.

User Story:
Als Nutzer möchte ich mich mit E-Mail und Passwort anmelden können, um Zugriff auf meine persönlichen Daten zu erhalten.

Mögliche Akzeptanzkriterien:

User Story:
Als Fachanwender möchte ich eine Kundenliste nach Status und Branche filtern, um gezielt Kunden für Kampagnen auszuwählen.

Akzeptanzkriterien:

User Story:
Als Projektleiter möchte ich einen Projektstatusbericht als PDF exportieren können, um ihn an Stakeholder zu versenden.

Akzeptanzkriterien:

„Die Funktion ist benutzerfreundlich.“
„Die Performance ist gut.“

Problem: Nicht testbar. Was ist „benutzerfreundlich“? Was ist „gut“?

Besser:

„Button triggert REST-Call auf Endpoint /api/v1/…“

Problem: Technische Details gehören in Design/Dokumentation, nicht in Akzeptanzkriterien.

Besser:

Stakeholder erwartet stillschweigend Dinge, die nie ausgesprochen wurden.

Beispiel:

Lösung:

Akzeptanzkriterien fangen alles ein, was fachlich gewünscht ist – inklusive „Nice to have“ und Zukunftswünschen.

Folge:

Lösung:

Wenn Akzeptanzkriterien erst zur Abnahme „nachgezogen“ werden, handelt es sich oft um eine Rationalisierung der bereits umgesetzten Lösung – nicht um echte Kriterien.

Lösung:

Akzeptanzkriterien für [User Story-Titel]:

Explizit ausgeschlossene Punkte vermeiden spätere Enttäuschungen – gerade in komplexen Projekten mit vielen Stakeholdern.

Akzeptanzkriterien sind der natürliche Ausgangspunkt für Tests:

In größeren Organisationen verschärfen sich die Probleme rund um Akzeptanzkriterien:

Bewährte Ansätze:

Müssen Akzeptanzkriterien immer vollständig sein, bevor eine Story in den Sprint geht?
Sie sollten so vollständig sein, dass das Team den Umfang versteht und verlässlich planen kann. Kleinere Ergänzungen im Sprint sind möglich – aber keine grundlegende Neuinterpretation der Story.

Wer entscheidet letztlich, ob die Akzeptanzkriterien erfüllt sind?
In Scrum typischerweise der Product Owner, häufig in Abstimmung mit relevanten Stakeholdern. Grundlage sind die vereinbarten Kriterien und die Definition of Done.

Wie detailliert sollten Akzeptanzkriterien sein?
So detailliert wie nötig, so knapp wie möglich. Alles, was für das Verständnis relevant ist, gehört hinein. Technische Details nur dann, wenn sie fachlich sichtbar werden (z. B. Sicherheits- oder Compliance-Anforderungen).

Brauchen wir für jede User Story Akzeptanzkriterien?
Ja, wenn es um fachlich relevante Stories geht. Für rein technische Aufgaben (Refactoring, Infrastruktur) können andere Formen der Beschreibung ausreichen. Wichtig ist, dass auch dort klar ist, wie Erfolg gemessen wird.

Akzeptanzkriterien im Scrum sind mehr als eine Formalie. Sie:

Wenn Sie Akzeptanzkriterien bewusst einsetzen, verbessern Sie nicht nur Ihre User Stories, sondern die gesamte Zusammenarbeit im Scrum-Team.

Wenn Sie Ihre bestehenden Backlogs, Refinement-Prozesse und Akzeptanzkriterien professionell überprüfen und auf ein konsistentes Niveau bringen möchten, lohnt sich ein externer Blick von erfahrenen Scrum- und Projektmanagement-Experten. So identifizieren Sie schnell die größten Hebel und etablieren eine Praxis, die zu Ihren Teams, Ihrer Organisation und Ihren Projekten passt.