Startseite
Wissen kompakt
Akzeptanzkriterien

Akzeptanzkriterien

Inhaltsverzeichnis: Definition – Kontext – Vorteile – Beispiele – Erstellung – Unterschied zur Definition of Done – Tipps – Download – Hinweise

Wissen kompakt: Akzeptanzkriterien definieren Bedingungen, durch die eine Anforderung oder eine User Story erfüllt und vom Stakeholder akzeptiert wird.

Akzeptanzkriterien Definition

Stakeholder formulieren Erwartungen an Produkte – als Anforderungen. Idealerweise sind Anforderungen eindeutig, vollständig, verständlich, widerspruchsfrei, redundanzfrei und korrekt formuliert. Doch in der Realität der Produktentwicklung sieht dies häufig anders aus. Immer wieder gibt es Berichte, wonach Projekte und Entwicklungen scheitern, weil die Qualität von Anforderungen nur unzureichend war. Hier helfen Akzeptanzkriterien. Sie definieren Bedingungen, durch die eine Anforderung erfüllt und vom Stakeholder akzeptiert wird. In anderen Worten: Akzeptanzkriterien konkretisieren Anforderungen.

Ihr Zweck liegt darin, möglichst eindeutig und objektiv zu bestimmen, ob eine Funktionalität genauso beschaffen ist, wie es sich der Anwender, Nutzer, Kunde – kurz der Stakeholder – vorstellt. Alternativ werden sie daher auch als Confirmation of Satisfaction deklariert.

Akzeptanzkriterien - Bedingungen die Anforderungen konkretisieren

Akzeptanzkriterien im agilen und klassischen Kontext

Akzeptanzkriterien werden in der Produktentwicklung und insbesondere in der Softwareentwicklung häufig genutzt. Gerne wird im Kontext agiler Vorgehensweisen darauf verwiesen, dass Backlog Items im Allgemeinen und User Storys im Besonderen Akzeptanzkriterien beinhalten müssen.

Doch auch in klassischen Vorgehensmodellen wie bspw. dem V-Modell XT ist die Verwendung von Akzeptanzkriterien üblich. Das V-Modell XT spricht in diesem Zusammenhang von Abnahmekriterien, die definieren, welche Kriterien die Lieferung erfüllen muss, um den Anforderungen zu entsprechen. Interessanterweise werden Akzeptanzkriterien im Scrum Guide nicht erwähnt.

Vorteile von Akzeptanzkriterien

Akzeptanzkriterien bieten einige Vorteile:

Sie rücken die Erwartungen des Anwenders in den Fokus.
Sie erhöhen das Verständnis der Beteiligten und schaffen Klarheit in Bezug auf Anforderungen bzw. User Storys.
Sie liefern klare Anhaltspunkte, was alles im Zuge der Implementierung erledigt werden muss.
Sie liefern den Input zu Akzeptanztests.
Sie fördern die Kommunikation zwischen den Beteiligten.

Beispiele für Akzeptanzkriterien

Idealerweise sollten Akzeptanzkriterien einfach, eindeutig und kurz formuliert werden. Hier finden Sie einige Beispiele:

User Story:

Als Besucher eines Online-Shops möchte ich verschiedene Artikel in einem Warenkorb sammeln, um diese in einem Vorgang zu kaufen und per Lieferservice zu erhalten.

Akzeptanzkriterien:

Drückt der Besucher im Online-Shop auf den “In den Warenkorb legen”-Button, sollte sich die Anzahl der Items in seinem Warenkorb um die ausgewählte Produktmenge erhöhen.
Legt der Besucher im Online-Shop einen Artikel in den Warenkorb, der sich dort bereits befindet, sollte sich die Anzahl des Artikel entsprechend erhöhen und nicht derselbe Artikel ein zweites Mal angelegt werden.
Der Besucher im Online-Shop kann eine Bestellung nur auslösen, wenn er alle Pflichtfelder (Name, Anschrift, E-Mail, Telefonnummer, Zahlungsmethode) ausgefüllt hat.
Erfolgt die Bestellung als Gast ohne Login, muss der Besucher die Ware per Vorkasse mit Kreditkarte oder PayPal bezahlen.

Die Erstellung von Akzeptanzkriterien

In der Praxis haben sich drei Techniken zur Formulierung von Akzeptanzkriterien bewährt:

das Arbeiten mit Listen,
das Arbeiten mit Szenarien,
das freie Ableiten.

Beispiel Listen:

Es ist ein sicheres Passwort mit mehr als 8 und weniger als 256 Zeichen inklusive Groß- und Kleinschreibung, Sonderzeichen und Ziffern zu verwenden.

Passwort	Erwartetes Ergebnis	Grund
A$9a	Fehler	zu kurz
AaBbCc1122	Fehler	keine Sonderzeichen
??aaa11122	Fehler	keine Großbuchstaben
??AAA11122	Fehler	keine Kleinbuchstaben
AbcDeFgH	Fehler	keine Zahlen
ThisIs#A1Password	Korrekt

Beispiel Szenario:

Als Kinobesucher möchte ich online in einem Profil meine Präferenzen speichern können, damit ich jede Woche per Newsletter entsprechend informiert werde.

Szenario: Kinobesucher speichert Präferenzen
Voraussetzung: Profil mit Pflichtfeldern E-Mail-Adresse, bevorzugte Filmkategorie(n) und die Zustimmung zur Datenschutzvereinbarung ist vorhanden.
Wenn: Wenn neue Filme der bevorzugten Filmkategorie ins Kinoprogramm aufgenommen werden,
Dann: wird ein Newsletter mit den entsprechenden Inhalten automatisch generiert
Und: und dem Kinobesucher per Mail geschickt.

Dieses Vorgehen ist Teil eines Behavior Driven Developments und firmiert unter Gherkin-Syntax (Feature, Given, When, Then bzw. Szenario, Voraussetzung, Wenn, Dann und Und).

Beispiel freies Ableiten:

Als Filmliebhaber möchte ich über neue Filme informiert werden, um zu wissen, welche Filme als nächstes im Kino laufen.

Wie oft möchte der Filmliebhaber informiert werden?
Wann möchte der Filmliebhaber informiert werden?
Wie möchte der Filmliebhaber informiert werden?
Über welche Art von Filme möchte der Filmliebhaber informiert werden?
…

Das freie Ableiten erfolgt über das Hinterfragen von Schlüsselwörtern (Verben, Adjektiven und Substantiven) insbesondere durch W-Fragen (wer, wann, wie häufig etc.).

Zusätzlich könnte auch beim freien Ableiten ein kleiner Merksatz helfen: Stellen Sie sich vor, die User Story ist fertig implementiert und kann nun getestet werden. Was schauen Sie sich an, um festzustellen, dass sie wirklich fertig ist?

Akzeptanzkriterien und Definition of Done – was ist der Unterschied?

Auch wenn der Scrum Guide Akzeptanzkriterien nicht explizit erwähnt, so kennt er doch die Definition of Done (DoD). Sie ist eine Checkliste mit Qualitätskriterien, die beschreibt, welche Kriterien erfüllt sein müssen, damit die Erstellung eines Produkts als erledigt betrachtet werden kann. Das führt zur Frage: wo liegen die Unterschiede zwischen beiden Hilfsmitteln?

Es gibt vor allem einen wesentlichen Unterschied: Akzeptanzkriterien beziehen sich immer konkret auf ein Backlog Item bzw. eine User Story. Sie sorgen für Klarheit, was im Rahmen der konkreten User Story umzusetzen ist und sie sind die Basis für Akzeptanztests. Die DoD bezieht sich auf die generelle Arbeit mit User Storys, die Kriterien sind also invariant. Somit ist der Scope zwischen beiden Hilfsmitteln unterschiedlich. Darüber hinaus “zahlen” Akzeptanzkriterien auf die sogenannte Definition of Ready ein und ihre Erfüllung kann auch ein Kriterium der DoD darstellen.

In manchen Publikationen wird erwähnt, dass Akzeptanzkriterien gesetzliche Anforderungen, Normen oder Regeln sein können, dies macht aber wenig Sinn. Akzeptanzkriterien konkretisieren spezifische Anforderungen, invariante Aspekte wie die Einhaltung von Normen sind deutlich besser in einer Definition of Done aufgehoben. Eine DoD wird selten angepasst, Akzeptanzkriterien hingegen werden immer pro User Story neu definiert.

Tipps für das Arbeiten mit Akzeptanzkriterien

Hier finden Sie eine Liste mit Tipps bei der Verwendung von Akzeptanzkriterien, die das Arbeiten in Organisationen erleichtert:

Akzeptanzkriterien sollten vor der Implementierung formuliert werden, denn so steigt die Wahrscheinlichkeit, die Erwartung des Kunden und nicht die Bedürfnisse der Entwickler zu adressieren. Gegebenenfalls lassen sich auch weitere Anforderungen identifizieren, die vor der Umsetzung mit Stakeholdern oder einem Stellvertreter bspw. dem Product Owner oder dem Produktmanager diskutiert werden können.
Jede Anforderung, jedes Backlog Item, jede User Story sollte vor der Implementierung mindestens ein Akzeptanzkriterium haben.
Akzeptanzkriterien sollten unabhängig testbar sein, so dass Akzeptanztests eindeutig scheitern oder bestanden werden.
Sie sollten auf das Ergebnis – also das WAS – und nicht auf die Lösung – dem WIE – abzielen. Es geht nicht um technische Details.
Sie dürfen von Teammitgliedern /Entwicklern formuliert werden, müssen aber vom Product Owner / Produktmanager als Stellvertreter der Stakeholder verifiziert werden.
Sie sollten nicht zu spezifisch formuliert werden, um die Entwickler nicht zu sehr einzuschränken. Es geht darum, entsprechende Intentionen zu verstehen und nicht darum, 100 kleine Tests für eine einzelne Anforderung zu implementieren. Gleichzeitig sollten sie aber so klar und eindeutig sein, dass korrespondierte Aufwände geschätzt werden können.
Sie können auch als Beispiele formuliert werden, denn durch Beispiele verstehen Beteiligte leicht, worum es inhaltlich geht.
Es empfiehlt sich auch, mit Stakeholder ein gemeinsames Verständnis über die Kriterien zu gewinnen.

Wollen Sie den Akzeptanzkriterien Guide kostenlos downloaden?

Alles Wichtige über Akzeptanzkriterien auf einen Blick.

Was sind Akzeptanzkriterien und wie werden sie im agilen und klassischen Kontext genutzt?
Wie werden Akzeptanzkriterien erstellt und welche Vorteile bietet die Verwendung?
Welche Beispiele gibt es und welche welche Tipps gibt es für das Arbeiten mit Akzeptanzkriterien?

Wissen auf 7 Seiten zum Mitnehmen.

Zum Download des Guides

Impuls zum Diskutieren:

Gibt es einen wesentlichen Grund, warum Beispiele selten als Akzeptanzkriterien genutzt werden?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

Eine Empfehlung zum praktischen Umgang mit Akzeptanzkriterien finden Sie im Beitrag: Boost your Backlog.

Hier finden Sie einen Podcast zum Thema: Akzeptanzkriterien richtig einsetzen. Ein Gespräch von Oliver Winter und Tim Klein.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt: