Wozu Akzeptanzkriterien dienen
Akzeptanzkriterien legen fest, unter welchen Bedingungen eine Änderung angenommen wird. Auftraggebende, Entwicklung und Test einigen sich damit auf das Ergebnis. Eine Implementierungsvorgabe wie „React Hook verwenden“ kann eine technische Einschränkung sein, beschreibt aber noch kein beobachtbares Verhalten.
Ein gutes Kriterium nennt Kontext, Handlung und prüfbares Resultat. „Der Export soll schnell sein“ reicht nicht: Zielwert, Datenmenge und Messmethode müssen zuerst vereinbart werden. Die Ticketbeschreibung erklärt Problem und Umfang; die Kriterien beschreiben die Annahme. Die teamweite Definition of Done für Reviews und Tests ersetzt keine aufgabenspezifischen Kriterien.
Bestätigte Anforderung oder Annahme?
„Kunden exportieren“ bestimmt weder Dateiformat noch Berechtigung, Spalten oder Verhalten bei leerem Ergebnis. Das sind Entscheidungen, keine Details, die man aus Gewohnheit ergänzen darf. Ein Vorschlag kann sinnvoll sein, wird aber erst nach Bestätigung zur Anforderung. Trenne deshalb im Ticket ausdrücklich „bestätigt“, „vorgeschlagen“ und „offen“.
Drei Beispiele
Funktion – Berichtexport. Schwach: „Alle Daten bequem exportieren.“ Nach Abstimmung besser: „Personen mit der Berechtigung Berichte laden eine UTF-8-CSV mit allen durch die aktuellen Filter erfassten Zeilen herunter, auch außerhalb der sichtbaren Seite.“ Spalten und leeres Ergebnis brauchen eigene Bestätigung; schreibe sie nicht ungefragt dazu.
Fehler – Anmeldung. Schwach: „Login funktioniert wieder.“ Besser: „Mit gültigem Konto und aktivierter Zwei-Faktor-Authentifizierung öffnet sich nach Passwort-Reset und korrektem Code eine Sitzung; der gemeldete Fehler tritt nicht auf.“ Das gilt nur, wenn der Fehler unter genau diesen Bedingungen reproduzierbar ist. Halte Schritte und Umgebung fest.
Technische Aufgabe – API-Upgrade. Statt „v2 einbauen, ohne etwas kaputtzumachen“ benenne die Zielumgebung und prüfe, ob betroffene Rechnungsanfragen weiterhin die vereinbarten Felder und Statuscodes liefern und die Integrationstests gegen v2 bestehen.
Wann Given / When / Then hilft
Das Format eignet sich für Abläufe, bei denen Vorbedingungen und Reihenfolge das Ergebnis verändern, etwa eine Anmeldung. Bei einer einfachen Textänderung fügt es kaum Klarheit hinzu. Eine PHP-Aktualisierung benötigt vielmehr Zielversion, betroffene Integrationen und konkrete Prüfungen. Verwende nur so viele Kriterien, wie eine Annahmeentscheidung tatsächlich braucht.
Prüfe vor dem Formulieren Ziel, Umfang und offene Entscheidungen mit dem Tool zur Ticket-Bereitschaft. Die Ausgabe ist ein Gesprächsentwurf. Die Checkliste zur Aufgabenbereitschaft und der Vergleich mit Definition of Ready helfen bei der Einordnung.