Abnahmekriterien: Wie man sie verfasst

Akzeptanzkriterien sind der „Bestanden/Nicht bestanden“-Test für eine Story, der vor Beginn der Arbeit festgelegt wird: die zulässigen Formate, konkrete Beispiele und die Unterschiede zur Definition von „Fertig“.

Akzeptanzkriterien sind die Bedingungen, die eine Story erfüllen muss, um akzeptiert zu werden: ein Bestanden/Nicht bestanden-Test, 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 diese richtig formuliert, wird die Schätzung einfacher, die Demo schreibt sich wie von selbst, und „fertig“ ist kein Verhandlungspunkt mehr. Sind sie jedoch zu vage, haben Sie eine Funktion ausgeliefert, 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 Verfeinerungssitzung teilgenommen hat, und der dennoch genau wüsste, was er zu prüfen hat. 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 und niemand dazu den Code lesen muss.

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“), ist sie 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 eine Aktion ausführt, reagiert das System auf eine bestimmte Weise. Das Format bewährt sich dadurch, dass es Sie dazu zwingt, alle drei Elemente zu benennen (die Vorbedingung, den Auslöser und das beobachtbare Ergebnis) – genau das, was bei einem vagen Kriterium außer Acht gelassen wird.

Beispiele für Abnahmekriterien

Eine Anmeldegeschichte, geschrieben 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, dann wird das Konto für 15 Minuten gesperrt und dem Benutzer wird angezeigt, wie lange die Sperre noch dauert.
  • Wenn auf der Anmeldeseite das E-Mail-Feld leer ist, dann ist die Schaltfläche „Absenden“ deaktiviert.

Ein Beitrag zum Thema „Filtern der Ergebnistabelle“, verfasst in Form einer Checkliste:

  • Der Filter wird bei der Auswahl angewendet, ohne dass es eine separate Schaltfläche „Anwenden“ gibt.
  • 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 und 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 weitere Rückfragen als bestanden oder nicht bestanden bewerten kann.

So verfassen Sie Akzeptanzkriterien

  • Erstellen Sie diese während der Backlog-Verfeinerung gemeinsam mit dem Team und nicht erst danach allein.
  • 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 als eine einzige getarnt sind. 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 Aufteilungsgrundlage. Die Liste ist ein Backlog, das die Funktion einer Checkliste erfüllt.

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 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 schlechteste 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 sich die Frage, die Sie bei jeder User Story stellen würden: Würde das Team dies eigenständig 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 stellen keine eigenständige Arbeit dar.

Wo dies jedoch versagt, sind eng miteinander verknüpfte Kriterien: „Das Formular validiert 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 niemand ihn zu Ende führt. „Ein Benutzer, der eine Passwortzurü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.

Abnahmekriterien im Vergleich zur Definition von „fertig“

Diese Begriffe werden ständig 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 muss erfüllt sein, damit die Story als ausgeliefert gilt? Story-Punkte beschreiben den Weg: Wie umfangreich der Arbeitsaufwand zwischen „Wir haben dies noch nicht“ und „Die Kriterien sind erfüllt“ ist. 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 Wunschdenken entspricht.

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, bevor Sie mit der Arbeit beginnen. Wenn ein Kriterium nicht fehlschlagen kann, ist es kein Kriterium. Und wenn Sie mehr als fünf 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, welche Funktion das Ergebnis erfüllen muss, nicht, wie es zu erstellen ist, und es gibt keine Teilbewertung: 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 die 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 es bestanden wird, ist dieser Teil der Story abgeschlossen; wenn Sie es bestehen können, ohne das Problem des Benutzers zu lösen, handelt es sich um eine verschleierte Anforderung.

Worin besteht 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, geprü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 für sie 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