User Stories sind ein inzwischen weit verbreitetes Mittel für das Anforderungsmanagement in agilen Softwareprojekten. Eine User Story beschreibt eine Anforderung aus Sicht des Kunden und besteht aus drei C’s: Card (Karte), Conversation (Konversation) und Confirmation (Akzeptanzkriterien). Die Karte, der sichtbare Teil einer Story, beschreibt den inhaltlichen Kern der Story mit Hilfe eines aussagekräftigen Satzes. Teil 2 einer User Story, die Konversation, ist der wichtigste Teil der Story. Konversation bedeutet, dass Details und konkrete Ausprägung der Story erst während ihrer Entwicklung im Dialog zwischen Product Owner und Entwicklungsteam besprochen werden. Confirmation, der dritte Teil einer User Story, sind ihre Akzeptanzkriterien. Akzeptanzkriterien sind eine Menge von Geschäftsregeln, die die Story konkretisieren und beschreiben, wann die Story fertig im Sinne der “Definition of Done” ist. Sie liefern klare und messbare Kriterien, was der Product Owner will und wann er mit der Story zufrieden ist.

Während die ersten beiden C’s, Story-Karte und Konversation, von vielen Teams gut angenommen und praktiziert werden, hapert es häufig beim dritten C, den Akzeptanzkriterien. Ich habe in mehreren Projekten die Erfahrung gemacht, dass Akzeptanzkriterien sowohl vom Product Owner als auch vom Team eher stiefmütterlich behandelt werden. Entweder werden sie gar nicht geschrieben oder in 5 Minuten als lieblose Liste schnell noch der Story hinzugefügt, damit der Scrum Master im Sprint Planning nicht meckert.

Im Folgenden möchte ich einige Argumente dafür liefern, dass Akzeptanzkriterien ein essentieller Pflichtbestandteil von User Stories sind, die nicht länger vergessen oder ignoriert werden dürfen:

Akzeptanzkriterien fokussieren Geschäftswert
Akzeptanzkriterien sind die stabilen Eckpfeiler einer User Story. Sie zwingen den Product Owner im Vorfeld der Story intensiv darüber nachzudenken, was er wirklich haben will. Sie helfen ihm auch zu erkennen, was er nicht braucht. Sie legen den Fokus der Story auf deren Geschäftswert und helfen dem Team, die Story besser zu verstehen und sich darauf zu konzentrieren, was wichtig ist. Es gilt der Grundsatz: Wofür es kein Akzeptanzkriterium gibt, ist auch nicht wichtig und wird auch nicht entwickelt.

Akzeptanzkriterien fördern Kommunikation und Zusammenarbeit
Konversation ist der wichtigste Teil einer User Story. Dies impliziert, dass Akzeptanzkriterien weniger wichtig sein müssen, was nur auf den ersten Blick richtig ist. Akzeptanzkriterien sind zwar eine Art geschriebene Spezifikation, allerdings immer als Ergebnis von zuvor statt gefundener Konversation. Niedergeschriebene Akzeptanzkriterien, idealerweise ergänzt durch erklärende Beispiele, sind quasi eine Art Beweis dafür, dass Konversation bereits vor dem Start der Entwicklung einer Story statt gefunden hat. Sie sind ein wichtiges Vehikel, um sowohl verbale Konversation als auch die enge Zusammenarbeit zwischen Product Owner und Team sicherzustellen und voranzutreiben.

Akzeptanzkriterien schaffen Verbindlichkeit
Während der Titel einer User Story relativ vage ist, beschreiben Akzeptanzkriterien eine Story sehr viel konkreter, ohne dass deren Offenheit in Bezug auf ihre detaillierte Ausgestaltung während der Implementierung eingebüsst wird. Hierdurch entsteht eine Verbindlichkeit, die dem Team hilft, die Story besser zu verstehen und im Vorfeld des Sprint besser einzuschätzen. Ausserdem erhält das Team die Gewissheit, dass der Product Owner seine Stories nicht während des Sprints immer weiter um neue Features aufbläht. Was zählt, sind die Akzeptanzkriterien. Alles andere werden neue Stories für zukünftige Sprints. Verbindlichkeit schafft die Basis für eine vertrauensvolle Zusammenarbeit.

Akzeptanzkriterien machen Stories messbar
Eine Story ist dann fertig, wenn alle ihre Akzeptanzkriterien umgesetzt sind. Wird die Umsetzung der Akzeptanzkriterien einer Story visualisiert, ist der Product Owner jederzeit über den aktuellen Entwicklungsstand informiert. Stories, deren Akzeptanzkriterien komplett umgesetzt sind, sind fertig. An ihnen wird nicht mehr entwickelt.

Akzeptanzkriterien sparen Zeit
Richtig ist, dass werthaltige und sorgfältig durchdachte Akzeptanzkriterien nicht mal eben in 5 Minuten runter geschrieben werden. Das Erarbeiten von Akzeptanzkriterien ist aufwändig und erfolgt idealerweise in Gruppen, z.B. im Rahmen eines Anforderungsworkshops. All dies kostet Zeit, muss im Vorfeld des Sprint Plannings erfolgen und liegt in der Verantwortung von häufig überlasteten Product Ownern. Klar muss jedoch sein, dass gute Akzeptanzkriterien am Ende Zeit sparen. Sie helfen allen Projektbeteiligten, sich aufs Wesentliche zu konzentrieren, keine unnötigen Features zu entwickeln, dann aufzuhören, wenn alle Geschäftsregeln implementiert sind und am Ende Software zu liefern, die der Kunde wirklich will.