Wie oft haben Sie schon erlebt, dass Entwickler und Tester darüber streiten, wie eine bestimmte Funktion implementiert werden soll? Oder diese ratlosen Blicke von Entwicklern, die sich nicht sicher waren, wie sie die gewünschte Funktion genau bauen sollen? Beides sind durchaus übliche Probleme in der Softwarewelt – zum Glück haben Sie ein mächtiges Werkzeug in Ihrem Arsenal, um sie zu lösen: Akzeptanzkriterien.
In diesem Leitfaden erläutere ich die Natur dieses Formats zum Festhalten von Anforderungen, erkläre ihre Rolle im Produktmanagement und zeige Ihnen, wie Sie großartige Akzeptanzkriterien schreiben.
Inhaltsverzeichnis
Welchen Zweck erfüllen Akzeptanzkriterien?
Wie sollten gut formulierte Akzeptanzkriterien aussehen?
Gängige Formate für Akzeptanzkriterien
Have an account? Log In
Was sind Akzeptanzkriterien
(und wie passen sie in Agile/Scrum?)
In der agilen Methodik ist ein Akzeptanzkriterium die kleinste Einheit einer funktionalen oder gestalterischen Anforderung, die agile Produktmanager (oder Business-Analysten) ihren Stories hinzufügen, um die verschiedenen Zustände und das Verhalten der geplanten Features klar an das Team zu kommunizieren.
Technisch gesehen können Sie Akzeptanzkriterien einsetzen, wo immer Sie möchten. Traditionell sind sie jedoch Bestandteil von User Stories, die wiederum Bestandteile von agilen Epics sind.
Um Akzeptanzkriterien besser zu verstehen, frischen wir zunächst unser Gedächtnis auf und sehen uns die einzelnen Elemente dieser Hierarchie an und welchen Zweck sie haben.
Epics
Epics sind Aufgaben, die die übergeordneten funktionalen und nicht-funktionalen Anforderungen eines großen Features oder einer zusammenhängenden Gruppe von Features enthalten. In der Regel deckt ein Epic einen vollständigen Anwendungsfall für Ihre Kunden ab und beinhaltet alle Features und Funktionalitäten, die zur Umsetzung dieses Anwendungsfalls benötigt werden.
Stellen Sie sich vor, Sie sind Teil des Produktteams von Spotify und möchten die Nutzung der App erweitern, indem Sie einen neuen Anwendungsfall für Menschen schaffen, die unterwegs sind und keinen Internetzugang haben.
Um diesen Anwendungsfall abzudecken, könnten Sie eine große neue Funktion namens „Offline-Modus für Spotify“ hinzufügen. Dies kann zu einem Epic in Ihrem Produkt-Backlog werden, das sämtliche Anforderungen enthält, damit Nutzer auch ohne Internet Musik hören können – inklusive mehrerer User Stories mit spezifischen Anforderungen für einzelne Teile dieses Features.
User Stories
User Stories sind kleiner dimensioniert und stehen für ein einzelnes, klar abgegrenztes Stück Funktionalität innerhalb eines Epics. Sie sind überschaubare Arbeitspakete, die das Agile-Team innerhalb einer Iteration liefern kann.
Ein zentrales Merkmal einer User Story ist, dass die darin beschriebene Funktionalität etwas Vollständiges und potenziell Nutzbares darstellen sollte.
Wenn Sie beispielsweise eine Online-Dateispeicher-App bauen und den Nutzern erlauben möchten, ihre hochgeladenen Dateien umzubenennen, wären Arbeiten im Frontend (UI und Nutzererlebnis der Umbenennung) sowie Backend (Speicherung des neuen Namens) nötig.
Damit das Feature vollständig und nutzbar ist, müssen beide Aufgaben erledigt und Frontend sowie Backend miteinander verknüpft werden. All das würde Ihr Team im Rahmen einer einzigen User Story bearbeiten.
Würde nur das Backend umgesetzt, wäre diese Aufgabe keine echte Story, da das Ergebnis für den Nutzer nicht komplett und nutzbar wäre.
Um dem Entwicklungsteam mitzuteilen, wie das Feature aussehen und sich verhalten soll, schreibt der Product Owner für diese Story Akzeptanzkriterien.
More Articles
Akzeptanzkriterien in User Stories
Schließlich gibt es noch die kleinsten Elemente in der Hierarchie der Software-Anforderungen: die Akzeptanzkriterien. Sie stehen für einzelne Nutzungsszenarien dieser Funktionalität oder für Informationen, die das Entwicklerteam bei der Umsetzung der Story benötigt.
Im obigen Beispiel wäre ein Akzeptanzkriterium, dass beim Klick auf den ✏️Umbenennen-Button eines hochgeladenen Dokuments ein Textfeld mit dem bisherigen Dateinamen vorausgefüllt erscheint.
Definition of Done (ja, ist etwas anderes als Akzeptanzkriterien!)
Manchmal verwechseln Product Owner (vor allem, wenn sie noch neu in dieser Scrum-Rolle sind) die Definition of Done mit den Akzeptanzkriterien.
Ganz ehrlich: Auch mir war das am Anfang etwas unklar, denn beides sind „Kriterien, um zu überprüfen, ob das Feature fertig ist“.
Der einzige Unterschied besteht darin, dass die Definition of Done die Vollständigkeit im Hinblick auf die Entwicklungsprozesse des Teams repräsentiert.
Während die Akzeptanzkriterien funktionale Anforderungen darstellen (wie das Feature aussehen und sich verhalten soll).
Das bedeutet, dass die Definition of Done für alle Stories, die das Team umsetzt, gleich bleibt, sofern sie nicht im Rahmen der Retrospektiven geändert wird. Die Akzeptanzkriterien hingegen sind für jede Story einzigartig, da sie die Funktionsweise dieses Features beschreiben.
Hinweis: Einige Product-Management-Tools ermöglichen es, sowohl die Definition of Done als auch die Akzeptanzkriterien bei Ihren Stories zu hinterlegen.
So könnte der Anmeldeprozess in diesem Format aussehen.
Da wir nun wieder in Erinnerung haben, worum es bei Epics und Stories geht und wie sich die Akzeptanzkriterien darauf beziehen, gehen wir jetzt der Frage nach, warum Product Owner überhaupt Akzeptanzkriterien schreiben.
