Akzeptanzkriterien
Requirements EngineeringDie konkreten, überprüfbaren Bedingungen, die eine Funktion erfüllen muss, damit sie als fertig gilt. Sie werden vor der Umsetzung vereinbart – damit „fertig“ für alle dasselbe bedeutet.
Akzeptanzkriterien machen aus einer User Story etwas Prüfbares. Sie beschreiben beobachtbares Verhalten – was das System unter welchen Bedingungen tut – und keine technische Lösung. Entscheidend ist der Zeitpunkt: Sie entstehen, bevor jemand programmiert, nicht bei der Abnahme.
Bewährt hat sich das Format Gegeben–Wenn–Dann: Gegeben ist eine Ausgangslage, wenn der Nutzer etwas tut, dann ist ein bestimmtes Ergebnis sichtbar. So ein Kriterium liest sich fast wie ein Testfall – und genau das wird später daraus.
Ich schreibe Akzeptanzkriterien nie allein. Am Tisch sitzen die fachlich verantwortliche Person, jemand aus der Entwicklung und idealerweise jemand, der testet. Können die drei die Kriterien nicht in einer Sitzung formulieren, ist die Anforderung noch nicht reif – und das ist die wertvollste Erkenntnis, die man vor der Umsetzung haben kann.
Kriterien schützen außerdem den Umfang. Kommt mitten im Sprint der Satz „nur noch eine Kleinigkeit“, sind die vereinbarten Kriterien der neutrale Maßstab: Gehört das zur Anforderung, oder ist es eine neue? Das erspart Diskussionen, die sonst persönlich werden.
Wie viele Akzeptanzkriterien braucht eine User Story?
Drei bis sieben sind ein gesunder Bereich. Werden es deutlich mehr, ist die Story meist zu groß und sollte geteilt werden.
Was ist der Unterschied zur Definition of Done?
Akzeptanzkriterien gelten für eine einzelne Anforderung und beschreiben ihr Verhalten. Die Definition of Done gilt für alle Anforderungen gleichermaßen und beschreibt Qualität – getestet, dokumentiert, ausgeliefert.