Akzeptanzkriterien helfen Entwicklung, Review und Abnahme dabei, dasselbe Ergebnis zu erwarten. Sie sollten konkret genug sein, um geprüft werden zu können, aber nicht unnötig technische Lösungen vorwegnehmen.
1. Das Ziel muss klar sein
Ist verständlich, welches Nutzer- oder Geschäftsproblem gelöst werden soll? Kriterien ohne erkennbares Ziel führen schnell zu einer Sammlung isolierter Detailanforderungen.
2. Beobachtbares Verhalten beschreiben
Formuliere, was aus Sicht der Nutzer oder des Systems passieren soll. „Der Button verwendet Komponente X“ ist meist kein Akzeptanzkriterium; „Nach dem Speichern wird die Änderung angezeigt“ schon.
3. Kriterien einzeln überprüfbar machen
Ein Kriterium sollte sich eindeutig als erfüllt oder nicht erfüllt bewerten lassen. Vage Wörter wie „schnell“, „schön“ oder „intuitiv“ brauchen eine konkretisierte Bedeutung.
4. Relevante Randfälle berücksichtigen
Leere Eingaben, Grenzwerte, fehlende Berechtigungen oder bereits vorhandene Daten können das erwartete Verhalten verändern. Nicht jeder theoretische Sonderfall gehört ins Ticket – die wichtigen aber schon.
5. Fehlerfälle nicht vergessen
Was soll passieren, wenn eine Eingabe ungültig ist oder ein externer Dienst nicht erreichbar ist? Erwartete Fehlermeldungen und Zustände sollten dort beschrieben werden, wo sie fachlich relevant sind.
6. Keine versteckten Zusatzanforderungen
Wenn Sicherheit, Migration, Rollen, Logging oder Kompatibilität relevant sind, sollten sie sichtbar im Ticket stehen und nicht erst im Review auftauchen.
7. Nicht die Umsetzung diktieren
Akzeptanzkriterien definieren primär das gewünschte Ergebnis. Technische Leitplanken gehören nur dann hinein, wenn sie tatsächlich Voraussetzung oder bewusste Architekturvorgabe sind.
8. Schnellcheck vor dem Start
Fragen:
Ist jedes Kriterium verständlich?
Ist es überprüfbar?
Sind wichtige Rand- und Fehlerfälle enthalten?
Ist Soll-Verhalten statt Implementierungsdetail beschrieben?
Kann ein Reviewer später nachvollziehen, wann die Aufgabe erfüllt ist?