Abnahmekriterien: Wie man sie verfasst

Akzeptanzkriterien sind der „Bestanden/Nicht bestanden“-Test einer Story, der vor Beginn der Arbeit festgelegt wird – die Formate, die funktionieren, Beispiele dafür sowie die Unterschiede zur Definition von „fertig“.

Akzeptanzkriterien sind die Bedingungen, die eine Story erfüllen muss, um akzeptiert zu werden – ein Test, bei dem es um „bestanden“ oder „nicht bestanden“ geht und der verfasst wird, bevor mit der Programmierung begonnen wird. Es gibt keine Teilpunkte: Entweder ist jedes Kriterium erfüllt oder nicht. Sie beschreiben, was das Ergebnis leisten muss, nicht, wie es zu erstellen ist. Und sie sind ein Test, keine zweite Beschreibung der Funktion. Wenn Sie sie mit Code erfüllen können, der das Problem nicht löst, handelt es sich nicht um Akzeptanzkriterien – sondern um getarnte Anforderungen.

Jede Geschichte birgt eine implizite Frage: Woran erkennen wir, dass sie abgeschlossen ist? Akzeptanzkriterien geben darauf eine klare Antwort, noch bevor die Arbeit beginnt. Sind sie richtig formuliert, wird die Schätzung einfacher, die Demo schreibt sich wie von selbst, und „fertig“ ist kein Verhandlungspunkt mehr. Sind sie jedoch vage formuliert, haben Sie eine Funktion veröffentlicht, auf die sich niemand geeinigt hat.

Was Akzeptanzkriterien sind – und was sie nicht sind

Ein gutes Abnahmekriterium ist etwas, das Sie einem Tester übergeben könnten, der noch nie an Ihrer Refinement-Sitzung teilgenommen hat, und dieser würde dennoch genau wissen, was er überprüfen muss. Es beschreibt ein Ergebnis, das der Benutzer beobachten kann, nicht die Implementierung, die es hervorbringt. „Verwenden Sie einen Redis-Cache“ ist kein Abnahmekriterium – es ist eine Lösung. „Die Ergebnisse einer Tabelle mit 10.000 Zeilen werden in weniger als einer Sekunde geladen“ ist hingegen ein Akzeptanzkriterium, da jeder dies testen kann, ohne dafür den Code lesen zu müssen.

Es handelt sich auch nicht um eine Wunschliste. Jedes Kriterium muss überprüfbar sein. Wenn eine Aussage nicht überprüft werden kann – „die Seite ist intuitiv“, „die Leistung ist gut“ –, dann ist es kein Kriterium, sondern eine Hoffnung. Streichen Sie sie oder machen Sie sie messbar.

Die beiden Formate, die funktionieren

Verwenden Sie Given/When/Then für Verhaltensweisen, die vom Zustand abhängen, und eine einfache Checkliste für eine Reihe unabhängiger Anforderungen. Die meisten Teams greifen bei allem auf Given/When/Then zurück; widerstehen Sie diesem Drang. Eine Checkliste lässt sich schneller lesen und ist schwerer aufzublähen, wenn die Story lediglich lautet: „Diese fünf Punkte müssen zutreffen.“

Gegeben / Wenn / Dann

Ausgehend von einem Anfangszustand: Wenn der Benutzer etwas tut, reagiert das System auf eine bestimmte Weise. Das Format beweist seinen Nutzen, indem es Sie dazu zwingt, alle drei Elemente zu benennen – die Vorbedingung, den Auslöser und das beobachtbare Ergebnis –, was genau das ist, was ein vages Kriterium außer Acht lässt.

Beispiele für Abnahmekriterien

Eine Anmeldegeschichte, verfasst im „Given/When/Then“-Format:

  • Wenn sich ein registrierter Benutzer auf der Anmeldeseite befindet, und er eine korrekte E-Mail-Adresse und ein korrektes Passwort eingibt, dann gelangt er auf sein Dashboard.
  • Wenn ein registrierter Benutzer dreimal ein falsches Passwort eingibt, wird das Konto für 15 Minuten gesperrt, und er sieht, wie lange die Sperre noch dauert.
  • Wenn auf der Anmeldeseite das E-Mail-Feld leer ist, dann ist die Schaltfläche „Absenden“ deaktiviert.

Eine Anleitung zum Thema „Filtern der Ergebnistabelle“, verfasst in Form einer Checkliste:

  • Der Filter wird bei der Auswahl angewendet – es gibt keine separate Schaltfläche „Anwenden“.
  • Zwei Filter werden mit „UND“ kombiniert, nicht mit „ODER“.
  • Durch das Löschen aller Filter wird die vollständige, unsortierte Liste wiederhergestellt.
  • Eine leere Ergebnismenge zeigt den Status „Keine Treffer“ an, nicht eine leere Tabelle.

Beachten Sie, was in beiden Fällen ausgelassen wird: die Datenbank, das Framework, die Namen der Komponenten. Sie beschreiben, was der Benutzer erhält, nicht, wie Sie dies bereitstellen – und jede Zeile ist ein Punkt, den ein Tester ohne Rückfrage an Sie als bestanden oder nicht bestanden bewerten kann.

So verfassen Sie Akzeptanzkriterien

  • Erstellen Sie diese während der Backlog-Verfeinerung gemeinsam mit dem Team – nicht allein und erst im Nachhinein.
  • Pro Zeile ein beobachtbares Ergebnis. Wenn in einer Zeile ein „und“ vorkommt, das eine konkrete Funktion erfüllt, handelt es sich um zwei Kriterien.
  • Nennen Sie den „Unhappy Path“. Der leere Zustand, das Timeout, die falsche Eingabe – genau dort verbirgt sich der Aufwand.
  • Konzentrieren Sie sich dabei auf das Verhalten, nicht auf das Design. Das Mockup befasst sich mit dem Layout; die Kriterien legen fest, was erfüllt sein muss.
  • Hören Sie bei etwa fünf auf.

Ab wie vielen Akzeptanzkriterien sind es zu viele?

Etwa fünf. Nicht, weil es eine Regel gibt, sondern weil eine Story, die zehn unterschiedliche, überprüfbare Bedingungen erfordert, zehn unterschiedliche Wertanteile umfasst – was bedeutet, dass es sich um mehrere Stories handelt, die vorgeben, eine einzige zu sein. Wenn die Liste lang wird, bilden die Akzeptanzkriterien selbst die Aufteilung.

Aufteilung nach Akzeptanzkriterien

Wenn eine Story mehr als fünf Akzeptanzkriterien aufweist, dienen diese Kriterien in der Regel als Aufteilung. Die Liste ist ein Backlog, das die Funktion einer Checkliste übernimmt.

Akzeptanzkriterien dienen dazu, eine Story zu beschreiben. Sie sollen nicht die Story selbst sein. Wenn die Liste lang wird – sechs, acht, zehn Punkte –, hat das Team die Aufteilung oft bereits vorgenommen, ohne es zu bemerken. Jedes Kriterium ist ein kleiner Teil, den das Team ausliefern, vorführen und dann hinter sich lassen könnte. Die gesamte Liste als eine einzige Verpflichtung zu betrachten, zwingt das Team dazu, alles auf einmal in Angriff zu nehmen – was die schlimmste Kombination aus Umfang und Risiko darstellt, die man jemandem in einem Sprint auferlegen kann.

Um die Aufteilung vorzunehmen, nehmen Sie jedes Kriterium einzeln und stellen Sie die Frage, die Sie bei jeder User Story stellen würden: Würde das Team dies als eigenständiges Element veröffentlichen? Würde der Nutzer allein davon profitieren? Könnte es vorgeführt werden? Die Punkte, die diese Prüfung bestehen, sind User Stories. Die Punkte, die diese Prüfung nicht bestehen, gehören in der Regel zu einem der übrig gebliebenen Elemente – sie sind Teil des Umfangs einer Story, die Sie bereits abgetrennt haben, und keine eigenständigen Aufgaben.

Wo dies jedoch versagt, sind eng miteinander verknüpfte Kriterien – „das Formular überprüft die Eingabe und speichert sie in der Datenbank und zeigt eine Bestätigung an.“ Diese drei Punkte scheinen zwar aufteilbar zu sein, doch der Nutzer hat keinen Nutzen davon, wenn nur einer davon umgesetzt wird. Das lässt sich nicht nach Kriterien aufteilen; es handelt sich um eine einzige kleine Story, und die Aufzählungspunkte dienen lediglich der Gründlichkeit des Teams.

Abnahmekriterien im Vergleich zu Anforderungen

Eine Anforderung legt fest, was entwickelt werden soll. Ein Akzeptanzkriterium legt fest, woran Sie erkennen, dass Sie das Richtige entwickelt haben. „Benutzer können ihr Passwort zurücksetzen“ ist eine Anforderung – und Sie können diese mit einem Ablauf erfüllen, der so fehlerhaft ist, dass ihn niemand zu Ende führt. „Ein Benutzer, der eine Zurücksetzung beantragt, erhält innerhalb von zwei Minuten eine E-Mail, deren Link nach einer Stunde abläuft“ ist ein Abnahmekriterium, da es sich um einen Test handelt, den der fehlerhafte Ablauf nicht besteht. Anforderungen legen den Umfang der Arbeit fest; Kriterien dienen als Kontrollinstanz.

Akzeptanzkriterien im Vergleich zur Definition von „fertig“

Diese Begriffe werden ständig miteinander verwechselt, dabei ist die Unterscheidung ganz einfach: Akzeptanzkriterien gelten pro Story; die Definition von „fertig“ ist global. Die oben genannten Kriterien beschreiben, was die Login-Story konkret leisten muss. Die Definition von „fertig“ – getestet, Code-Review durchlaufen, dokumentiert, auf der Staging-Umgebung bereitgestellt – gilt für jede Story, die das Team ausliefert. Eine Story kann ihre Akzeptanzkriterien erfüllen und dennoch nicht „fertig“ sein, da „funktioniert wie spezifiziert“ und „bereit zur Veröffentlichung“ unterschiedliche Maßstäbe sind. Sie benötigen beides.

Story-Punkte im Vergleich zu Akzeptanzkriterien

Akzeptanzkriterien beschreiben das Ergebnis – was erfüllt sein muss, damit die Story als ausgeliefert gilt. Story-Punkte beschreiben den Weg – wie umfangreich die Arbeit ist, die zwischen „Wir haben dies noch nicht“ und „Die Kriterien sind erfüllt“ liegt. Es handelt sich um zwei unterschiedliche Achsen. Werden diese miteinander vermischt, entstehen entweder quantifizierte Kriterien, was bedeutungslos ist, oder Punkteschätzungen ohne zugrunde liegende Kriterien, was reine Wunschvorstellungen sind.

Verändert das Hinzufügen eines Kriteriums die Schätzung? Manchmal. Ein Kriterium, das verborgene Arbeitsaufwände sichtbar macht – „muss für Screenreader zugänglich sein“ –, tut dies in der Regel, da es einen Aufwand benennt, der zuvor implizit war. Ein Kriterium, das lediglich eine bestehende Annahme präzisiert – „muss in Chrome und Safari funktionieren“, wenn dies ohnehin schon die unterstützten Browser waren –, sollte dies nicht tun. Die Reihenfolge ist entscheidend: zuerst die Kriterien, dann die Punkte. Eine Schätzung, bevor die Kriterien klar sind, ist eine Schätzung vor der Verfeinerung, und sie ist die häufigste Ursache für weit gestreute Abstimmungsergebnisse.

Schreiben Sie den Test vor der eigentlichen Arbeit. Wenn ein Kriterium nicht fehlschlagen kann, ist es kein Kriterium – und wenn Sie mehr als fünf davon haben, haben Sie wahrscheinlich mehr als eine Story.

Häufig gestellte Fragen

Was sind Abnahmekriterien?

Annahmekriterien sind die Bedingungen, die eine Story erfüllen muss, um akzeptiert zu werden – ein vor Beginn der Arbeit festgelegter Test, bei dem es um „bestanden“ oder „nicht bestanden“ geht. Sie beschreiben, was das Ergebnis leisten muss, nicht, wie es zu erstellen ist, und es gibt keine Teilpunkte: Jedes Kriterium ist entweder erfüllt oder nicht.

Wie formuliert man Akzeptanzkriterien?

Formulieren Sie jede einzelne so, als würden Sie sie einem Tester übergeben, der die Story noch nie gesehen hat. Verwenden Sie „Given/When/Then“ für zustandsabhängiges Verhalten oder eine einfache Checkliste für eine Reihe unabhängiger Anforderungen. Achten Sie darauf, dass sie testbar sind, konzentrieren Sie sich auf Ergebnisse und beschränken Sie sich auf etwa fünf – bei mehr als fünf handelt es sich bereits um mehrere Stories.

Was ist der Unterschied zwischen Abnahmekriterien und Anforderungen?

Anforderungen legen fest, was zu entwickeln ist; Akzeptanzkriterien legen fest, woran Sie erkennen, dass es richtig ist. Eine Anforderung kann durch Code erfüllt werden, der am eigentlichen Ziel vorbeigeht. Ein Akzeptanzkriterium ist ein Test – wenn er bestanden wird, ist dieser Teil der Story abgeschlossen; wenn Sie ihn bestehen können, ohne das Problem des Benutzers zu lösen, handelt es sich um eine getarnte Anforderung.

Was ist der Unterschied zwischen Akzeptanzkriterien und der Definition von „fertig“?

Akzeptanzkriterien gelten pro Story – sie beschreiben, was diese bestimmte Story leisten muss. Die Definition von „fertig“ ist eine übergreifende Checkliste, die für jede Story gilt (getestet, überprüft, dokumentiert, bereitgestellt). Eine Story kann ihre Akzeptanzkriterien erfüllen und dennoch nicht als fertig gelten, wenn sie die teamweite Hürde nicht nimmt.

Wer verfasst die Akzeptanzkriterien?

Der Product Owner ist dafür verantwortlich, doch sie werden gemeinsam mit dem Team im Rahmen der Verfeinerung erarbeitet. Der Product Owner legt den Rahmen für das Ergebnis fest; die Entwickler und Tester bringen die Randfälle zur Sprache. Akzeptanzkriterien, die im Nachhinein allein verfasst werden, sind genau jene, bei denen der Fall übersehen wird, der im Produktivbetrieb zu Fehlern führt.

Weiterführende Literatur