Wie man ausgezeichnete Akzeptanzkriterien schreibt (Mit Beispielen)
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
Du willst mehr vom The CPO Club?
Registriere dich für eine kostenlose Mitgliedschaft, um diesen Artikel vollständig zu lesen:
Have an account? Log In
Welchen Zweck erfüllen Akzeptanzkriterien?
Wie sollten gut formulierte Akzeptanzkriterien aussehen?
Gängige Formate für Akzeptanzkriterien
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.
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.
Das Flow-Format ist die beste Option, wenn Sie Nutzerempathie schaffen möchten (genau wie beim BDD), aber keine strenge Struktur verfolgen wollen.
Alle auf denselben Stand bringen mit Akzeptanzkriterien
Akzeptanzkriterien sind mächtige Werkzeuge in den Händen von Product Ownern. Sie ermöglichen es, eine einzige Informationsquelle zu schaffen und das Team auf die Vision für die jeweilige Funktion auszurichten.
Für weitere Leitfäden wie diesen und viele andere hilfreiche Ressourcen für Produktmenschen abonnieren Sie unseren Newsletter!
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.
Was ist der Zweck des Schreibens von Akzeptanzkriterien?
Kann ich eine User Story nicht einfach so beschreiben, wie ich will, ohne Akzeptanzkriterien einzufügen? Was bringt es überhaupt, Akzeptanzkriterien zu schreiben?
Natürlich können Sie Ihre Stories so schreiben, wie Sie möchten. Ich empfehle Ihnen jedoch, Akzeptanzkriterien als Format zur Formulierung Ihrer Anforderungen zu verwenden, denn dieses Vorgehen bringt zahlreiche Vorteile mit sich. Hier sind einige zur Überlegung.
Sie fördern verhaltensorientiertes Denken
Wenn Sie sich für das BDD-Format (Behavior Driven Development) bei den Akzeptanzkriterien entscheiden (später mehr dazu), dann beschreiben Ihre Akzeptanzkriterien die Reise der Nutzer, wenn sie das betreffende Feature verwenden.
Das Schöne an diesem Ansatz ist, dass Sie Ihren Fokus von rein technischen Anforderungen weglenken und Features aus der Sicht der Nutzer betrachten. Dadurch können Sie sich besser vorstellen, was sie erleben und fühlen, wenn sie mit Ihrem Feature interagieren.
Es ist sehr häufig, dass der Product Owner erkennt, dass die eigentlich vorgestellte Funktionalität doch nicht die beste ist, wenn er sie aus Sicht der Nutzer betrachtet.
Auch ich habe das schon mehrfach selbst erlebt. Zum Beispiel, als ich Anforderungen für einen Formeleditor (er war Bestandteil eines SaaS-Produkts zur Finanzanalyse, das wir damals entwickelten) geschrieben habe, wollte ich den Bearbeitungsprozess so gestalten:
- Eine Bearbeiten-Schaltfläche neben der Formel.
- Ein Klick auf die Bearbeiten-Schaltfläche macht das Eingabefeld der Formel editierbar und zeigt die Buttons ✅ Speichern und ❎ Abbrechen an.
- Ein Klick auf einen der beiden Buttons beendet den Bearbeitungsmodus, und je nach Auswahl erscheint dort entweder die neue gespeicherte Version oder die alte Version der Formel.
Dieses Verhalten erscheint logisch, oder?
Nun, bis ich begonnen habe, Nutzungsszenarien für Analysten zu notieren, und einen erheblichen Usability-Fehler entdeckt habe. Analysten optimieren die Formel üblicherweise durch viele kleine Änderungen und prüfen nach jedem Schritt das Berechnungsergebnis, bis sie das gewünschte Ergebnis haben.
Die Art, wie ich das Editieren vorgesehen hatte, wäre für meine Zielnutzer extrem mühsam gewesen, da sie 20-30 Mal hintereinander den Editiermodus hätten betreten und verlassen müssen. Als mir dieser Fehler klar wurde, änderte ich sofort die Akzeptanzkriterien und forderte einen Formeleditor, der Änderungen in Echtzeit zulässt.
Sie unterstützen eine einheitliche Quelle der Wahrheit
Als „junger“ Product Manager war meine größte Herausforderung, Produktanforderungen mit Menschen unterschiedlicher Fachrichtungen oder sogar verschiedenen Teams zu kommunizieren. Das Problem war, dass jeder die Anforderungen anders verstanden hat, wodurch die Kommunikation sehr unklar wurde.
Da empfahl mir ein erfahrener Produktmanager, das Konzept einer einheitlichen Quelle der Wahrheit anzuwenden: Anforderungen ganz eindeutig zu formulieren (dabei kann KI beim Requirements Gathering helfen), sie allen zu kommunizieren und alle zu bitten, ihre Arbeit ausschließlich auf diese ausformulierten Anforderungen zu stützen.
Das war ein voller Erfolg – alle hatten damit das gleiche Verständnis davon, wie das Feature funktionieren sollte, und bei Meinungsverschiedenheiten wurde immer auf die Anforderung Bezug genommen.
Akzeptanzkriterien sind ein hervorragendes Mittel, um eine einzige vertrauenswürdige Quelle zu schaffen, da sie das Feature klar und leicht verständlich beschreiben und eine hohe Granularität aufweisen (da sie alle Hauptaspekte des Features abdecken sollten).
Sie verbessern die Qualität der Abnahmetests
Für Softwareentwickler dienen Akzeptanzkriterien als Produktanforderungen, denen sie beim Entwickeln des Features folgen. Für Ihr Qualitätssicherungsteam hingegen bieten Akzeptanzkriterien einige zusätzliche Vorteile:
Sie helfen, Testfälle zu priorisieren. Wenn Ihr Softwaretestteam viele Testfälle für dieses Feature hat und nicht genügend Zeit zur Verfügung steht, um alle durchzuführen, werden sie die Testszenarien, die den Akzeptanzkriterien entsprechen, zuerst priorisieren und ausführen, da diese die kritischsten Nutzerabläufe abbilden.
Sie dienen als Abnahme-Checkliste. Dieser Punkt gilt sowohl für Qualitätssicherungsteams als auch für Produktverantwortliche, die das Feature abnehmen müssen. Akzeptanzkriterien dienen – wie der Name vermuten lässt – als Checkliste, anhand derer über das Bestehen oder Nichtbestehen des Features entschieden wird. Werden ein oder mehrere Akzeptanzkriterien nicht erfüllt, wird das Qualitätssicherungsteam die Story wieder eröffnen und das Entwicklerteam bitten, die fehlende Funktionalität nachzuliefern.
Zusammengefasst sind Akzeptanzkriterien für Produktverantwortliche ein unschätzbares Werkzeug, um Produktanforderungen klar zu kommunizieren. Aber wie schreibt man gute Akzeptanzkriterien? Dabei helfe ich Ihnen im Folgenden.
Wie sollten gut geschriebene Akzeptanzkriterien aussehen?
Die Qualität der von Ihnen formulierten Akzeptanzkriterien wirkt sich direkt auf die Qualität der Features aus, die Ihr Team liefert. Mit einem klaren Verständnis davon, was gebaut und wie es getestet werden soll, wird Ihr Team das Feature exakt so umsetzen, wie Sie es sich vorgestellt haben – mit minimalen Schwierigkeiten.
Um hervorragende Akzeptanzkriterien zu schreiben, sollten Sie auf Folgendes besonders achten.
Klarheit
Die größte Sünde, die ein Produktverantwortlicher begehen kann, ist es, unklare und vage Akzeptanzkriterien zu verfassen. Sie können die Vorstellung eines gemeinsamen Verständnisses vergessen, wenn mehrere Interpretationen dessen möglich sind, was Sie geschrieben haben.
Um den Unterschied zu verdeutlichen, zeige ich Ihnen ein Beispiel.
Was verstehen Sie aus diesem Satz? Können Sie mir sagen, wie der Geldautomat den Kartentyp nutzt, um zu entscheiden, ob der Benutzer authentifiziert werden soll oder nicht? Authentifiziert der Automat den Nutzer, wenn alle diese Kriterien gleichzeitig erfüllt sind, oder reicht bereits eines davon?
Wenn Sie dieses Akzeptanzkriterium Ihren Entwicklern geben, werden diese Sie mit Rückfragen überschütten und verlangen, dass Sie Ihre Anforderungen klarer formulieren. Lassen Sie uns das verbessern.
Das sieht doch gleich viel besser aus, oder? Mit diesen Akzeptanzkriterien haben wir auch die oben genannten Fragen beantwortet. Der Geldautomat muss den eingelegten Kartentyp unterstützen und alle drei Kriterien müssen gleichzeitig erfüllt sein, damit der Automat die Authentifizierung durchführt.
Profi-Tipp: Formulieren Sie Ihre Akzeptanzkriterien SMART (spezifisch, messbar, erreichbar, relevant, testbar). Ja, ich habe den letzten Punkt zu "testbar" geändert, da dies ein wesentliches Merkmal effektiver Akzeptanzkriterien ist.
Lesbarkeit
Abgesehen davon, dass Sie Unklarheiten vermeiden, sollten Sie Ihre Akzeptanzkriterien einfach halten und auf ausgefallene Begriffe oder komplexe Sprache verzichten.
Ich bin sicher, dass Sie ein Team von hochqualifizierten Superstars haben, die selbst die ausgefallensten und komplexesten Worte und Formulierungen der englischen Sprache mühelos lesen und verstehen können. Dennoch wollen Sie deren kognitive Fähigkeiten nicht mit dem Entschlüsseln Ihrer Texte vergeuden.
Sagen Sie also lieber dies ...
... statt dieses.
Ich kann mir vorstellen, dass auch Sie den ersten Akzeptanzkriterien-Text gar nicht erst ganz gelesen haben, um keine Zeit und geistige Energie zu verschwenden!
Abdeckung der Fälle
Der Teufel steckt im Detail. Manchmal merkt man erst sehr spät in der Entwicklungsphase, dass ein unangenehmer Fall in der Funktionalität übersehen wurde – dann muss man im Nachhinein einen weiteren Verbesserungspunkt anlegen oder sogar alles noch einmal überarbeiten.
Klingt vertraut, oder?
Je mehr Fälle du im Vorfeld in deinen Akzeptanzkriterien berücksichtigst, desto geringer ist die Wahrscheinlichkeit, dass du später mit genau solchen Szenarien bei deinen Backlog-Items konfrontiert wirst.
Schauen wir uns nun die folgenden Akzeptanzkriterien an.
Fällt dir hier etwas Merkwürdiges auf? Auf den ersten Blick ist die Anforderung klar: E-Mail-Adresse eingeben, auf Senden klicken und die Person erhält Zugriff. In Wirklichkeit sind jedoch viele Fälle nicht berücksichtigt worden:
- Wenn die E-Mail-Adresse bereits in der Liste der Nutzer ist, die Zugriff auf das Dokument haben, solltest du vielleicht eine Fehlermeldung anzeigen, die den Nutzer darauf hinweist.
- Du verschickst eine Einladung per E-Mail, also wäre es sinnvoll, anzuzeigen, ob die Einladung bereits angenommen wurde oder nicht, zum Beispiel in der geteilten Übersicht.
- Wenn die Einladung noch nicht angenommen wurde, wäre ein „Einladung erneut senden“-Button hilfreich.
Es gibt auch Negativfälle, in denen du das Verhalten deiner Funktion festlegst, wenn etwas leer ist oder ein Fehler auftritt.
Aktiver Einsatz visueller Hilfsmittel
Waren die von mir geteilten Akzeptanzkriterien für dich völlig klar? Als ich das Feld „Personen und Gruppen hinzufügen“ erwähnt habe, war dir sofort klar, worum es geht?
Manchmal reichen Worte nicht aus, um dem Team Requirements klar zu machen – dann ist es besser, etwas zu zeigen, anstatt es nur zu beschreiben. Lass mich die Akzeptanzkriterien jetzt ein wenig verbessern.
Gehe ich richtig in der Annahme, dass du mit diesen Akzeptanzkriterien und dem Bild direkt daneben problemlos verstanden hättest, was ich meine? Ich bin mir sicher, dass du das hättest.
Damit hätten wir die „Akzeptanzkriterien“ der Akzeptanzkriterien abgedeckt – schauen wir uns jetzt die verschiedenen Typen und Formate an, die Produktteams dafür nutzen.
Gängige Formate für Akzeptanzkriterien
Ich will ehrlich mit dir sein: Ich verwende so gut wie nie dasselbe Format für all meine User Stories. Der Grund ist, dass verschiedene Formate für Akzeptanzkriterien für unterschiedliche Anwendungsfälle gut geeignet sind – und es ist nicht immer ratsam, sich zum ständigen Einsatz eines Formats zu zwingen.
Deshalb wähle ich das Format anhand der jeweiligen Story und der Art der Informationen, die ich in die Akzeptanzkriterien schreiben will.
Schauen wir uns nun einige der gängigen Formate und deren jeweilige Beispiele für Akzeptanzkriterien an.
BDD-Format
BDD steht für Behavior-driven Development und ist ein Framework, das Software- und Produktteams dazu anregt, Anforderungen anhand des Verhaltens der Endnutzer:innen zu formulieren.
Im Sinne der Formulierung von Anforderungen aus Nutzersicht folgt das Format für BDD-Akzeptanzkriterien dieser Vorlage:
Gegeben: Die Ausgangsbedingung für das spezifische Nutzungsverhalten.
Wenn: Die Aktion, die die Nutzerin/der Nutzer durchführt.
Dann: Das Ergebnis dieser Aktion.
Wenn du also erklären möchtest, wie die Auszahlungsfunktionalität eines Geldautomaten funktioniert, könnten deine Akzeptanzkriterien wie folgt aussehen:
Das Gegeben/Wenn/Dann-Format eignet sich besonders gut, wenn du im Team Empathie für die Nutzerbedürfnisse schaffen möchtest, indem der Nutzer:innenfokus betont wird.
Checklisten-Format
Im Gegensatz zu BDD (auch bekannt als „szenarienorientiertes Format“) stellt dieses Format nicht den Standpunkt der Endnutzer:innen in den Vordergrund. Es geht vielmehr darum, die Regeln festzuhalten, denen die Geschäftslogik einer Funktion folgen soll (deshalb auch der alternative Begriff „regelorientiert“). Und so sehen sie aus:
Dieses Format eignet sich besonders, wenn die zu erklärende Logik komplex ist, denn es hilft dir, diese in mehrere kleine Regeln zu unterteilen, die leichter nachvollziehbar und umsetzbar sind.
Ablauf-Format
Dies ist wahrscheinlich das Format, das ich am häufigsten verwende.
Das Flow-Format ähnelt dem BDD-Format, da es ebenfalls die Sicht des Nutzers widerspiegelt. Im Gegensatz zu BDD erzwingt es jedoch keine strenge Struktur (Given/When/Then). Daher sind Sie frei, die einzelnen Schritte, die der Benutzer ausführt, in beliebiger Weise zu beschreiben.
So könnte der Anmeldeprozess in diesem Format aussehen.
Das Flow-Format ist die beste Option, wenn Sie Nutzerempathie schaffen möchten (genau wie beim BDD), aber keine strenge Struktur verfolgen wollen.
Alle auf denselben Stand bringen mit Akzeptanzkriterien
Akzeptanzkriterien sind mächtige Werkzeuge in den Händen von Product Ownern. Sie ermöglichen es, eine einzige Informationsquelle zu schaffen und das Team auf die Vision für die jeweilige Funktion auszurichten.
Für weitere Leitfäden wie diesen und viele andere hilfreiche Ressourcen für Produktmenschen abonnieren Sie unseren Newsletter!
