User Story Akzeptanzkriterien (Abnahmekriterien) wie ein Profi schreiben!

In meinem letzten Beitrag, User Story Best Practices: Ein Leitfaden für agile Anforderungen, bin ich kurz auf das Schreiben von Akzeptanzkriterien eingegangen. Diesmal werde ich über die Grundlagen hinausgehen und Ihnen einige Tipps und Beispiele geben, wie Sie gute Abnahmekriterien schreiben können.

Zunächst möchte ich die Frage beantworten: „Was ist der Unterschied zwischen User Stories und Akzeptanzkriterien?“

User Stories vs. Akzeptanzkriterien – sie sind NICHT das Gleiche!

Zur Klarstellung: Acceptance Criteria (auch bekannt als Conditions of Satisfaction) sind keine User Stories. Es ist ein weit verbreiteter Fehler, sie für austauschbar zu halten.

Was sind User Stories und was sind Akzeptanzkriterien?

Akzeptanzkriterien sind Anforderungen an die Umsetzung einer User Story. Eine gut geschriebene User Story, gepaart mit effektiven Abnahmekriterien, kann den Geschäfts- und Entwicklungsteams helfen, eine Brücke zwischen Geschäftszielen – die aus Worten bestehen – und technischen Fähigkeiten – die aus Code bestehen – zu schlagen. Aber was genau ist der Unterschied?

Die User Story definiert einen Geschäftsbedarf, indem sie das WER, WAS und WARUM einer Funktion beschreibt.

Akzeptanzkriterien hingegen sind die Bedingungen, die erfüllt sein müssen, bevor eine Funktion als veröffentlichungsreif angesehen wird. Sie beschreiben das von der Funktion erwartete Verhalten und geben den Entwicklern eine Anleitung für die Implementierung der Feature.

Jede User Story hat in der Regel mindestens ein Akzeptanzkriterium, könnte aber noch viel mehr haben, je nachdem, wie kompliziert die User Story ist.

User Stories sind wie die Skizzen eines Künstlers – sie beschreiben, was Sie erreichen wollen.
Akzeptanzkriterien sind die Farbe, die Ihre User Story zum Leben erweckt!

To learn more about the parts of the User Story model, watch: What is a User Story? The Card, the Conversation, and the Criteria.

Werden User Stories mit Akzeptanzkriterien nur in der agilen Entwicklung verwendet?

User Stories sind ein zentrales Artefakt in der agilen Softwareentwicklung, das Ihr Team ans Ziel bringen kann. Aber was ist, wenn Sie nicht mit Agile arbeiten?

Unternehmen, die Software auf weniger agile und eher „wasserfallartige“ Weise entwickeln (Wagile, Scrumafall usw.), drücken kritische oder komplexe Stakeholder-Anforderungen oft im User-Story-Format aus. Auf diese Weise können sie eine Anforderung schnell erfassen und die Erstellung von Abnahmetests erleichtern.

In einer schlanken/agilen Umgebung werden Akzeptanzkriterien oft schon bei der Erstellung einer User Story erfasst. Während Iterationsplanungssitzungen können dann zusätzliche Akzeptanzkriterien hinzugefügt werden.

Perspektive ist entscheidend!

Akzeptanzkriterien sind Bedingungen, die erfüllt werden müssen, um den in einer User Story beschriebenen Geschäftswert zu liefern. Sie decken die Feinheiten ab, die für die Implementierung einer Funktion erforderlich sind.

Während die User Story aus der Perspektive des Benutzers geschrieben wird, werden die Akzeptanzkriterien aus der Perspektive des Produkts geschrieben.

3 Beispiele für Abnahmekriterien aus einem realen Projekt

Betrachten wir die User Story:

Als Besucher der Website möchte ich alle Flüge sehen, die von meinem ausgewählten Flughafen zu meinem gewünschten Zielort am angegebenen Datum abfliegen, um den Flug zu buchen, der meinen Reiseanforderungen entspricht.

Um sicherzustellen, dass das Produkt das liefert, was die User Story verspricht, halte ich die folgenden Akzeptanzkriterien fest:

• Der Besucher erhält eine Liste mit allen verfügbaren Flügen, die den Suchkriterien entsprechen.
• Wenn keine Flüge den Suchkriterien entsprechen, kann der Besucher Folgendes auswählen:
  • alternative Daten
  • alternative Zielorte
  • alternative Abflüge
• Sobald der Besucher einen Flug auswählt, wird das Reservierungsformular angezeigt.

Das sind die Akzeptanzkriterien, die ich festgelegt habe, als ich die Benutzergeschichte zum ersten Mal schrieb.

Warum es entscheidend ist, gute Akzeptanzkriterien zu haben

Mit Abnahmekriterien ein gemeinsames Verständnis aufbauen

Der Zweck der Akzeptanzkriterien ist:

• Sicherzustellen, dass die Visionen der Geschäftsbereiche und der technischen Teams übereinstimmen.
• Das gegenseitige Verständnis zwischen Autoren, Entwicklern und Stakeholdern zu fördern.
• Den Entwicklern und Testern die funktionalen und nicht-funktionalen Anforderungen an eine digitale Lösung zu vermitteln.

Entwickler und Stakeholder müssen ein gemeinsames Verständnis davon haben, was wirklich wichtig ist, wenn es um User Stories geht. Dazu müssen sie sich auf die Regeln einigen, die sie beim Schreiben einer User Story befolgen, da diese Regeln bestimmen, was das User Story-Team als voll funktionsfähiges Produkt betrachtet.

Acceptance Criteria sind Ihre Chance, eine Story zu verfeinern, indem Sie detailliert beschreiben, was Sie von einem Produkt erwarten. Sie sind der endgültige Qualitätsnachweis für jede User Story und helfen sowohl den Entwicklern als auch den QA-Testern, genau zu verstehen, woran sie arbeiten, was zu weniger Missverständnissen, schnellerem Feedback und reibungsloseren Testläufen führt. Indem klar definiert wird, was von der Story erwartet wird, können Verwirrung, doppelter Aufwand oder Fehler während der Entwicklung minimiert werden.

Akzeptanzkriterien verbessern Schätzungen und erleichtern Abnahmeprüfungen (User Acceptance Testing)

Darüber hinaus erleichtern die Abnahmekriterien die Aufwandsabschätzung. Je mehr die Entwickler darüber wissen, was sie liefern müssen, desto besser können sie den für die Implementierung erforderlichen Aufwand abschätzen. Ohne geeignete Spezifikationen ist es für Entwickler schwierig, den Umfang der Arbeit und die Dauer der Umsetzung zu verstehen.

Ein weiterer Vorteil von Akzeptanzkriterien ist, dass sie auch zur Definition negativer Testszenarien oder Fehlerbedingungen verwendet werden können. Dabei handelt es sich um Situationen, in denen das Produkt auf eine bestimmte Weise reagiert (z. B. ein ungültiges Passwortmuster oder eine ungültige Kombination von Artikeln in einer Bestellung).

Zu einem bestimmten Zeitpunkt müssen Akzeptanztests geschrieben werden, um zu überprüfen, ob jede Funktion ordnungsgemäß funktioniert. Die Akzeptanzkriterien der User Story sollten die Konstruktion dieser Tests leiten. Daher ist es eine gute Strategie, Akzeptanzkriterien zu erstellen, die spezifisch genug sind, um den QA-Testern klare Anweisungen zu geben.

Abnahmekriterien – Formate, die Sie kennen sollten

Wenn Sie jemals an einem Projekt gearbeitet haben, haben Sie sich wahrscheinlich gefragt: „Wie schreibe ich Akzeptanzkriterien; welches Format sollte ich verwenden?“

Es gibt viele Möglichkeiten, Akzeptanzkriterien zu formulieren. Das Ziel eines jeden Formats besteht jedoch darin, sicherzustellen, dass jeder weiß, wie der Erfolg aussieht und wie er erreicht wird.

Das kann so einfach sein wie:

• Das System erlaubt es dem Benutzer, den Namen einzugeben und diese Information zu speichern.
• Das System sendet eine E-Mail an den Manager, wenn ein neuer Mitarbeiter eingestellt wird.

Dies mag wie eine triviale Angelegenheit klingen, aber es ist für Entwickler von entscheidender Bedeutung zu verstehen, was die Anwendung tun soll und nicht, wodurch Mehrdeutigkeiten reduziert werden und Sie sicherstellen können, dass sich das System in der erwarteten Weise verhält.

Die verschiedenen Formen von Akzeptanzkriterien

Die verwendeten Formate reichen von einfachen Checklisten bis hin zu komplexeren Geschäftsregeln und -bedingungen, haben aber alle den gleichen Zweck: das gewünschte Verhalten der Software in einer klaren, präzisen Weise zu erfassen.

Eine Checkliste ist eine Liste von Anweisungen, die beschreiben, was erreicht werden muss. Ein weiteres gängiges Format sind Business Rules und Bedingungen, d. h. eine Reihe spezifischer Regeln, die festlegen, wie sich Ihre Software verhalten soll. Einige Teams verwenden sogar Gegeben-Wenn-Dann Szenarien obwohl dies meist bei  Acceptance Testing verwendet wird.

Welches Format Sie wählen, hängt von der Situation und den am Projekt arbeitenden Personen ab; manchmal funktioniert ein Format besser als ein anderes. Unabhängig vom Format, ist es wichtig, dass Sie Ihre User Story Kriterien auf dem neuesten Stand halten. Sie wollen nicht zu spät feststellen, dass etwas nicht wie erwartet funktioniert oder dass Sie etwas Wichtiges vergessen haben!

Beispiel für Akzeptanzkriterien: Checklisten

Das Format der Checkliste ist eine recht einfache Methode, um zu vermitteln, was mit einer neuen Funktion oder Verbesserung erreicht werden soll. Es ist ein natürlicher Weg für den Geschäftsinhaber oder Projektmanager, die Anforderungen zu formulieren, und für das technische Team, diese zu bestätigen.

Eine Checkliste ist nicht nur ein einfacher Weg für alle, um zu verstehen, was getan werden muss, sondern es regt auch zu Gesprächen über die Details der einzelnen Punkte in der Liste an.

Dies ist ein Beispiel für eine User Story mit Akzeptanzkriterien in Form einer Checkliste, die die Entwickler darüber informiert, was die Story beabsichtigt:

Als neuer Nutzer kann ich einer Gruppe beitreten, um mich an einer Diskussion zu beteiligen.

Akzeptanzkriterien:

• Benutzer kann ein Profil erstellen
• Benutzer kann Gruppen durchsehen
• Benutzer kann eine Gruppe auswählen
• Benutzer kann beantragen, einer Gruppe beizutreten
• Benutzer kann Chats anderer Mitglieder lesen
• Benutzer können Chats kommentieren

Akzeptanzkriterien in Form von Business Rules (Geschäftsregeln) schreiben

Business Rules sind eine Form von Geschäftsanforderungen, die keine Beteiligung von Programmierern erfordern, um geändert zu werden. Sie eignen sich hervorragend als Akzeptanzkriterien.

Wenn eine Marketingabteilung beispielsweise Studenten, die in Florida leben, während der Wintersaison einen Rabatt von 10 % gewähren möchte, muss sie diese Option in den Business Rules festlegen. Die Marketingabteilung möchte in der Lage sein, diese Änderungen spontan vorzunehmen, um sich an aktuelle Marktveränderungen anzupassen und wettbewerbsfähig zu bleiben. Business Rules geben ihnen diese Möglichkeit.

In ihrer einfachsten Definition sind Business Rules Richtlinien, die Geschäftsaktivitäten definieren, auslösen oder einschränken. Sie sind ein integraler Bestandteil der User Stories und beschreiben die Prozesse, Definitionen und Einschränkungen, die für das Unternehmen gelten.

Bei Geschäftsregeln geht es nicht nur um Technologie – sie beziehen sich auf Menschen, Prozesse, geschäftliche Abläufe und Systeme. Sie helfen dem Unternehmen, seine Ziele zu erreichen.

Zur Klärung der Begriffe:

• Business Rules legen die Kriterien und Bedingungen für die Entscheidungsfindung fest.
• Eine User Story oder Business Requirement ermöglicht die Umsetzung und Einhaltung einer Business Rule.

Wenn Sie die Akzeptanzkriterien für eine User Story in Form von Geschäftsregeln definieren, können Sie eine komplexe Stakeholder-Anforderung schnell klären. Hier ist ein Beispiel für diesen Typ von Akzeptanzkriterien:

Um die Abbruchquote zu senken, können Underwriter Anträge auf Kfz-Versicherung innerhalb von 3 Geschäftstagen annehmen oder ablehnen.

Wann beginnt der Arbeitstag und wann endet er? Sind Wochenenden Arbeitstage? Solange Sie die Antwort auf diese Fragen nicht kennen, können Sie nicht messen, ob die Software die User Story korrekt umsetzt.

Die häufigste Form einer Business Rule ist eine Aussage über einen Sachverhalt. Um eine korrekte Umsetzung dieser User Story sicherzustellen, könnten Sie die Abnahmekriterien so schreiben, dass sie auf die spezifische Business Rule verweisen (oder sie sogar zitieren):

BR107: Der Geschäftstag beginnt montags bis freitags um 8:00 Uhr und endet um 17:00 Uhr UTC-7, außer an gesetzlichen US-Feiertagen.

Gherkin-Akzeptanzkriterien – Eine Ausarbeitung nach dem Geben-Wenn-Dann-Format

Das Gherkin-Format entwickelt sich zur bevorzugten Methode für das Schreiben von Akzeptanzkriterien, da sie leicht zu Akzeptanztests erweitert werden können.

Die Gherkin-Syntax ist einfach zu verstehen und leicht zu lesen; Sie beschreiben den Kontext (Gegeben), was passieren muss (Wenn) und was das Ergebnis sein sollte (Dann).

Zum Beispiel:

SZENARIO: Kunde mit langer Berufserfahrung und ausgezeichneter Bonität beantragt einen Kredit.
GEGEBEN Antragsteller ist seit mehr als 5 Jahren beschäftigt
UND die Kreditwürdigkeit ist ausgezeichnet
WENN Kunde Kreditantrag stellt
DANN Kredit genehmigen
UND Mitunterzeichner anfordern

Die Given-When-Then-Struktur ist besonders effektiv, da sie den Entwicklern genügend Kontext bietet, um zu verstehen, was sie erstellen müssen, ohne ihnen bei der Entwicklung in die Quere zu kommen.

Mit dem Gherkin-Format können Sie User Stories so aufschlüsseln und beschreiben, dass sie von Entwicklern leicht umgesetzt werden können.

Das Schreiben von Akzeptanzkriterien in Gherkin-Syntax konzentriert sich eher auf die Ausführung der Geschäftslogik als auf die technischen Details. Der Vorteil dieses Ansatzes besteht darin, dass Benutzertests und Akzeptanzkriterien von Business-Analysten, Domänenexperten und Testfachleuten und nicht nur von Entwicklern geschrieben werden können.

Gherkin ist einfach zu verstehen und leicht zu lesen. Gegeben, Wenn und Dann sind die drei wichtigsten Schlüsselwörter, aus denen die Gherkin-Syntax besteht:

• Gegeben (Kontext): Der Zusammenhang, in dem die Funktion verwendet wird. Dazu können gehören: Vorbedingungen, Umfeldangaben und alle anderen relevanten Informationen, die notwendig sind, um sicherzustellen, dass das Szenario das erwartete Ergebnis liefert.
• Wenn (Event): Das Ereignis, das die verwendete Funktion auslöst. Dies kann Folgendes umfassen: Aktionen, die von Benutzern durchgeführt werden, oder automatisierte Aktionen, die vom System selbst durchgeführt werden.
• Dann (Ergebnis): Das erwartete Ergebnis der Ausführung dieser Aktion. Dies kann eine Bestätigung dafür sein, dass etwas richtig gelaufen ist (z. B. eine Erfolgsmeldung), aber es kann auch ein Scheitern bedeuten (z. B. eine Fehlermeldung).

Da das Given-When-Then-Format beim Schreiben von Akzeptanzkriterien und User-Tests so beliebt ist, habe ich einen Blog-Beitrag nur über den Gegeben-Wenn-Dann-Ansatz mit dem Titel Mit Gherkin-Szenarien schnell und einfach Akzeptanzkriterien und Benutzertests erstellen geschrieben.

Akzeptanzkriterien in Form einer Funktionsliste schreiben

Wenn eine User Story komplex oder vielschichtig ist, können Ihnen die Akzeptanzkriterien helfen, den Arbeitsumfang für diese spezielle Story zu definieren. Indem Sie die User Story in einzelne Funktionen (das Was) unterteilen, können Sie besser verstehen, wie jeder Teil zum großen Ganzen beiträgt.

Eine Funktion kann so einfach sein wie das Drücken einer Taste oder das Eingeben eines Benutzernamens und Passworts. Es könnte auch etwas Komplexeres sein, wie das Ausfüllen eines ganzen Formulars.

Eine Funktionsliste hilft Entwicklern dabei, die Funktionalität und Merkmale klar zu verstehen, die für die Implementierung einer User Story gemäß den Erwartungen der Benutzer erforderlich sind.

Funktionale Dekomposition – eine einfache Technik zur Erstellung von Akzeptanzkriterien

Ein schneller Weg, um zu einer Funktionsliste zu gelangen, ist eine Technik namens Funktionaler Drill-down oder Feature-Dekomposition. Diese Methode wird häufig verwendet, um große User Storys aufzuteilen oder aufzuschlüsseln, und als Bonus erhalten Sie „nicht-funktionale Anforderungen“, die die Story erfüllen muss.

Ich habe einen Beitrag geschrieben, der dieses Thema ausführlicher behandelt und den Sie hier finden können: Funktionale und nicht-funktionale Anforderungen: Was sind sie und wie man sie erstellt?

Die Technik besteht darin, sich eine User Story anzusehen, um Folgendes zu identifizieren:

• Funktionen, die die Lösung erfüllen muss, und die zugehörigen Daten.
• Qualitätsanforderungen (auch bekannt als nicht-funktionale Anforderungen), die die Eigenschaften und Merkmale definieren, die die digitale Lösung aufweisen muss.
• Einschränkungen oder absolute Beschränkungen, Regeln, Gesetze, Vorschriften und Umgebungsfaktoren, die in der Lösung berücksichtigt werden müssen.

Zeit, die mit dem Schreiben schlecht formulierter User Stories und Anforderungen verbracht wird, ist verschwendete Zeit. Vermeiden Sie häufige Fehler und lernen Sie, klare Akzeptanzkriterien für Ihr Software-Team zu erstellen.

Beispiel für eine komplexe User Story (Epic) mit Acceptance Criteria

Betrachten wir die folgende User Story:

Als Bücherfreund kann ich ein Buch online bestellen, um es in aller Ruhe zu lesen.

Ihre Funktionen sind möglicherweise:

• Buch in den Einkaufswagen legen
• Zahlungsoption auswählen
• Lieferadresse und Versandart eingeben

Die Funktionen sind nicht sehr detailliert, aber für einen ersten Entwurf von User Story Criteria reicht das aus.

In einer agilen Umgebung werden die User Stories während der Entwicklung weiter ausgearbeitet. Die Akzeptanzkriterien für diese untergeordneten Stories werden später im Lebenszyklus der Softwareentwicklung definiert.

Beispiel für eine gut dimensionierte User Story mit Acceptance Criteria

Hier ist ein weiteres Beispiel, allerdings mit einer kleineren User Story:

Als Versicherungsagent kann ich einen Prämienrabatt für unfallfreie Fahrer gewähren, um mehr Kfz-Versicherungsverträge zu verkaufen.

in dieser User Story finden wir eine explizit genannte Funktion:

• Prämienrabatt berechnen

Achten Sie als nächstes auf implizite Funktionen. Ein Rabatt ist immer ein Prozentsatz des Basisbetrags. Das bedeutet, dass die Anwendung die Prämie kennen muss, um einen Prämienrabatt berechnen zu können.

Damit werden die Funktionen hinzugefügt:

• Prämienrabatt berechnen
• Prämie berechnen

Außerdem wird in der Story von „unfallfreien Fahrern“ als einer Gruppe von Personen gesprochen, die für diesen Prämiennachlass in Frage kommen. Wie kann die Anwendung „unfallfreies Fahren“ erkennen?

Im Gespräch mit dem zuständigen Sachbearbeiter stellen Sie fest, dass ein „unfallfreier Fahrer“ jemand ist, der in den letzten drei Jahren keinen Unfall oder Verkehrsverstoß hatte.

Anhand dieser neuen Informationen erfahren Sie, dass Sie eine Funktion benötigen, die das Fahrverhalten des Bewerbers auswertet, um zu entscheiden, ob er diesem Profil entspricht, ergo die Funktion „Fahrverhalten auswerten“.

• Prämienrabatt berechnen
• Prämie berechnen
• Fahrverhalten auswerten

Die Verwendung der funktionalen Zerlegung, um auf diese Ebene der Akzeptanzkriterien zu gelangen, ist eher für spätere Entwicklungsphasen geeignet, z. B. während der Release- und Sprint-Planung.

Hier sind einige weitere Beispiele für High Level Functional Criteria:

Closing Thoughts

Ich hoffe, dieser Blogbeitrag hat Ihnen einige nützliche Tipps und Tricks gegeben, wie Sie gute Akzeptanzkriterien für Ihre User Stories schreiben können.

Das Schreiben von Akzeptanzkriterien kann anfangs etwas schwierig sein, aber mit der Zeit wird es einfacher. Es ist wichtig, dass Sie sich durch diese Tipps nicht in Ihrer Kreativität einschränken lassen – betrachten Sie sie stattdessen als eine Reihe von Leitprinzipien, die Ihnen helfen werden, bessere User Stories zu erstellen.

Es ist hilfreich, sich anzugewöhnen, für jede User Story klare Abnahmekriterien zu definieren. Damit stellen Sie nicht nur sicher, dass Sie erkennen können, ob eine Funktion vollständig ist, sondern es kann Ihnen auch helfen, konzentriert zu bleiben, wenn Sie es mit schwierigen Benutzern zu tun haben und versuchen, ein kniffliges Problem zu lösen.

Um das Beste aus User Story Akzeptanzkriterien herauszuholen, muss man jedoch wissen, wie man sie effektiv einsetzt und wie man häufige Fallstricke vermeidet.

In der Zwischenzeit würde ich gerne Ihre Ansichten zu der Festlegung von Akzeptanzkriterien hören:

• Gibt es Überraschungen, die Sie bei dabei erlebt haben?
• Wie hat es Ihnen bei der Entwicklung Ihrer User Story geholfen?
• Haben Sie Erfahrungen mit User Stories, die Sie mit uns teilen möchten?

Wenn ich Sie um Ihre Hilfe bitten dürfte, teilen Sie diesen Beitrag bitte mit einem Freund, der diese Informationen gebrauchen kann oder hinterlassen Sie einen Kommentar mit Ihren Erfahrungen. 

Vielen Dank im Voraus! Ich schätze Ihr Feedback.