Akzeptanzkriterien für User Stories schreiben (mit dem Gherkin-Format)

Im letzten Artikel haben wir uns das User Story Template und die INVEST-Kriterien für gute User Stories angesehen.

Wahrscheinlich wird dir – wenn du seitdem mit User Stories experimentiert hast – aufgefallen sein, dass dadurch der Fokus auf den Nutzer, das was er erreichen will und vor allem auf das dahinterstehende „Warum“ geschärft wird. Die Beschreibung von dem was im Detail umgesetzt werden soll, fällt den meisten Menschen aber weiterhin schwer. Denn entweder gehen sie dabei zu sehr ins Detail oder sie bleiben zu vage und belassen es bei wenigen Erklärungssätzen.

Deshalb zeige ich dir heute, wie du Akzeptanzkriterien für deine User Stories schreiben kannst, mit denen du einfach und klar beschreibst, was letztlich entwickelt/umgesetzt werden soll.

Was sind Akzeptanzkriterien?

Egal ob agil oder klassisch: bei jeder Aufgabe muss klar sein, was eigentlich erreicht werden muss, bevor sie als erledigt gelten kann. Den Erfindern von SCRUM war das Thema sogar so wichtig, dass es im SCRUM-Guide ein eigenes Kapitel zur sogenannten „Definition of Done“ gibt.

Hinter dem Begriff „Definition of Done“ versteckt sich letztlich aber nichts anderes als eine Liste von Bedingungen, die erfüllt sein müssen, um die Bedürfnisse der Kunden zu befriedigen. Doch wie so oft, liegt der Teufel hier im Detail und der klassische Hinweis, dass Akzeptanzkriterien eindeutig und einfach formuliert werden sollen, hilft in der Praxis meist wenig.

Denn wenn es dann wirklich um das Schreiben von Akzeptanzkriterien geht, schwankt man immer zwischen zu viel und zu wenig. Manchmal erscheint einem eine User Story klar und einfach und deshalb schreibt man nur wenige erklärende Sätze. In anderen Fällen verspürt man hingegen den Drang, tief in die Details einzusteigen und oft finden sich dann technische Vorgaben in den Akzeptanzkriterien.

In beiden Fällen ist das Ergebnis oft Unmut bei den Entwicklern. Entweder beklagen sie sich über zu wenige Informationen oder sie lehnen die technischen Vorgaben als zu großen Eingriff in ihren Arbeitsbereich ab.

Glücklicherweise gibt es eine Lösung für dieses Problem: es handelt sich um das, etwas seltsam benannte, Gherkin-Format.

Das Gherkin-Format

Bevor es hier gleich um die Wurst – oder besser um die Gewürzgurke – geht, möchte ich kurz auf den Ursprung des hier verwendeten Formats eingehen. Es handelt sich um das sogenannte „Behavior Driven Development“.

Wenn du dich nun – als nicht IT-ler – fragst, warum dich das interessieren sollte, dann lies bitte noch kurz weiter!

Beim „Behavior Driven Development“ werden die Anforderungen an die Software nämlich anhand sogenannter Szenarien beschrieben. Und meist folgt diese Beschreibung einem bestimmten Format – wie eben der hier genutzten, sogenannten Gherkin-Sprache.

Bei genauerem Hinsehen zeigt sich, dass diese Beschreibungen genau das sind, was wir bei Akzeptanzkriterien von User Stories machen (wollen). Wir beschreiben das, was mit der User Story erreicht werden soll – aus Sicht des Nutzers. Und zwar so, dass wir anhand dieser Kriterien prüfen können, ob die User Story komplett umgesetzt ist.

Diese Gherkin-Beschreibungen werden aus den Elementen „Vorausgesetzt“, „Wenn“, „Dann“ sowie „Und“ zusammengesetzt.

Szenario	Alle Aktionen, die ein Nutzer machen kann (inkl. der “schlechten” Aktionen).
Vorausgesetzt	In welchem Kontext befinden wir uns?
Wenn	Welche Aktion wird durchgeführt?
Dann	Wie sieht die Reaktion aus?

Beispiel: Artikel genehmigen

Nehmen wir für ein ganz einfaches Beispiel folgendes Szenario an: In einer Redaktionssoftware soll es für den Chefredakteur die Möglichkeit geben, einen Artikel, der zur Veröffentlichung bereit ist, zu genehmigen.

Die User Story sähe dann wahrscheinlich wie folgt aus:

Als Chefredakteur
möchte ich, dass Artikel vor der Veröffentlichung von mir genehmigt werden müssen,
um eine abschließende Qualitätskontrolle durchführen zu können.

Die Akzeptanzkriterien, die du mit dem Gherkin-Format für diese Story formulieren könntest, sähen dann beispielsweise so aus:

Szenario	Chefredakteur genehmigt Artikel
Vorausgesetzt	Der Autor hat einen Artikel zur Veröffentlichung eingereicht.
Wenn	der Chefredakteur auf „genehmigen“ klickt,
Dann	wird der Artikel – je nach eingestelltem Veröffentlichungsdatum – veröffentlicht oder zur Veröffentlichung geplant.
Und	der Chefredakteur sieht eine Erfolgsmeldung, die anzeigt, dass der Artikel erfolgreich veröffentlicht/geplant wurde.
Und	an den Autor wird eine Benachrichtigung geschickt, dass sein Artikel genehmigt wurde.

Natürlich handelt es sich hierbei nur um ein mögliches Szenario und wahrscheinlich ist dir auch sofort aufgefallen, dass einige Anwendungsfälle – wie z.B. das Bearbeiten oder Ablehnen des Artikels – noch nicht beschrieben sind.

Was aber schon bei diesem einfachen Beispiel deutlich wird ist, dass – durch die Nutzung des Gherkin-Formats – klare und für alle verständliche Akzeptanzkriterien beschrieben werden können. Und das ganz ohne ein Wort über Code oder die dahinter liegenden Technologien verlieren zu müssen.

Und genau das ist es, was wir erreichen wollen: wir beschreiben die Funktionen auf einer fachlichen Ebene, ohne dem Entwickler, o.ä. technische Vorgaben zu machen.

Die Vorteile von Akzeptanzkriterien im Gherkin-Format

Du siehst also, dass das Gherkin-Format bei der Formulierung von Akzeptanzkriterien viele Vorteile bringt:

Als Product Owner hilft es dir dabei, Anforderungen auf einer fachlichen Ebene zu beschreiben, ohne in die technischen Details einsteigen zu müssen.
Diese systematische Vorgehensweise hilft Product Ownern auch dabei, fehlende Arbeitsschritte und andere offene Punkte zu identifizieren.
Entwickler und Designer bekommen eine detaillierte fachliche Beschreibung der Anforderungen ohne von (technischen) Vorgaben eingegrenzt zu werden.
Und Tester können ihre Testfälle letztlich auf Basis der Szenarien viel einfacher schreiben.
Insgesamt hilft die einheitliche und systematische Formulierung – über alle Stories hinweg – allen Beteiligten ein besseres gegenseitiges Verständnis zu erreichen.

Wichtig bei diesem Vorgehen ist jedoch darauf zu achten, dass der Fokus bei der Formulierung auf den fachlichen Anforderungen, dem Nutzer und dessen Verhalten liegen sollte. Immer wenn hier technische Details auftauchen, sollten deine Warnlampen angehen. Technische Details – wie Datenbanktabellen oder Codestücke – haben hier nichts verloren!

Wie du Akzeptanzkriterien im Gherkin Format schreibst

Letztlich ist das Schreiben von Akzeptanzkriterien im Gherkin Format nicht schwer. Probier es also am besten gleich selbst aus:

Suche dir eine User Story aus.
Sammle die Szenarien, d.h. alle Aktionen die ein Nutzer machen kann. In unserem Beispiel könnten die weiteren Szenarien sein: Der Chefredakteur will den Artikel bearbeiten, zur Überarbeitung zurückweisen und einen Vermerk dazu verfassen, …
Schreibe die Akzeptanzkriterien für jedes Szenario im Gherkin-Format auf (Vorausgesetzt-Wenn-Dann).
Solltest du bei diesen Beschreibungen zu viele “UND”-Verknüpfungen haben, dann prüfe, ob du sie in mehrere Beschreibungen unterteilen kannst.

Wahrscheinlich wirst du bei der Durchführung der oben genannten Schritte schnell dort angelangen, wo dir noch Details fehlen. Das ist aber kein Grund sich zu ärgern! Denn genau hier – im Aufdecken der Schwachstellen – liegt eine der wichtigsten Stärken des Gherkin-Formats. Denn es ist ein Glücksfall, wenn dir die Schwachstellen deiner User Stories zu einem so frühen Zeitpunkt auffallen und nicht erst, wenn z.B. die Entwickler etwas umgesetzt haben, was so gar nicht deinen Vorstellungen entspricht. Denn das erzeugt neben Frust nur unnötige Kosten und Verzögerungen.

Hast du bereits Erfahrungen mit dem Gherkin-Format gemacht? Hast du weitere Tipps zum Schreiben von Akzeptanzkriterien? Oder hast du noch Fragen? Dann schreib mir doch einfach einen kurzen Kommentar!