Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Interview mit einem Akzeptanzkriterium (Teil 1)

Das Konzept der User Story als Werkzeug für die Beschreibung und das Management von Anforderungen in agilen Softwareprojekten ist überwiegend anerkannt,  weit verbreitet und hat sich erfolgreich etabliert. Verglichen mit traditionellen Mitteln des Anforderungsmanagements geben User Stories Raum für Änderungen und unterstützen dabei, ein System entstehen zu lassen, das der Kunde tatsächlich will. Und eben keines, das zwar vor einem Jahr „in“ war und spezifiziert wurde, heute aber bereits von den dynamischen Entwicklungen eines schnelllebigen Marktes überholt und schon wieder „out“ ist.

Leider gibt es diesbezüglich noch kein kongruentes Meinungsbild. Denn auch wenn die Unschärfe einer User Story wesentlicher Teil ihrer Erfolgsgeschichte ist, so ist es eben genau diese Unvollständigkeit, die von vielen Entwicklungsteams noch nicht ausreichend als Einladung zur Konversation verstanden wurde. Um die Kluft zwischen Offenheit auf der einen und Konkretheit auf der anderen Seite zu überwinden, muss das Entwicklungsteam seinem Product Owner etwas versprechen: Dass es sich nämlich detailliert über die jeweilige User Story unterhält und im gemeinsamen Dialog kleine Feedbackschleifen etabliert, die zu einem gemeinsamen Verständnis führen sollen, wann eine Userstory tatsächlich vollständig umgesetzt und auf der Basis der Definition of Done „fertig“ ist.

bor!sgloger-Reporter David Holzer hat sich zu diesem Thema auf den Weg nach Backlogsen gemacht, um sich mit der Person zu treffen, die für viele Entwickler zu den wichtigsten Anhaltspunkten dafür gehört, was denn eigentlich beim Umsetzen von User Stories zu tun ist. Dieser Jemand konkretisiert im Sinne einer Leitplanke das Ziel einer User Story und ist für Tester und Product Owner ein wichtiges Hinweisschild für die Durchführung von Akzeptanztests, nachdem die Story (fertig) entwickelt und integriert wurde: das Akzeptanzkriterium.

David Holzer: Hallo, es ist schön, dass Sie meiner Einladung gefolgt sind. Für unsere Leser würde ich Sie kurz bitten, sich vorzustellen und zu umreißen, wer Sie eigentlich sind.

Akzeptanzkriterium: Ja, erst mal vielen Dank. Und es tut gut, dass Sie sich die Zeit für mich nehmen. Wissen Sie, ich werde nämlich ziemlich oft übergangen oder komme zu kurz oder oder … Stellen Sie sich vor: Manchmal werde ich sogar vergessen! Fast immer nehmen sich die Leute viel zu wenig Zeit für mich und reden immer nur sehr oberflächlich über mich. Dabei bin ich doch die Geschäftsregel, die eine User Story konkretisiert! Ich beschreibe doch das Verhalten einer User Story aus Sicht des zugrundeliegenden Geschäftsmodells! Aber irgendwie geht das im Eifer des Gefechts häufig unter (seufzt tief).

David Holzer: Vielleicht kann ich Ihnen mit meinen Fragen ja dabei helfen, dass dieser Missstand in Zukunft nicht mehr auftritt. Was tun sie außerdem?

Akzeptanzkriterium: Ich beschreibe außerdem eine konkrete Eigenschaft einer User Story. Damit gebe ich die Grenzen der User Story vor. Kurzum: Ich sage an, ob etwas „in scope“ oder „out of scope“ ist. Ich bin ja nicht so streng: Ich lasse bei den Inhalten doch mit mir verhandeln. Ehrlich gesagt liebe ich den Dialog, das finde ich einfach super, wenn die Menschen in einem Team miteinander reden. Mit diesem Dialog helfe ich bei der Antwort auf die Frage, wann eine User Story „fertig“ ist.

David Holzer: Das klingt nach einer sehr verantwortungsvollen Funktion, die Sie da haben. Ich wette, das ist noch nicht alles?

Akzeptanzkriterium: Na und ob das noch nicht alles ist! Stellen Sie sich vor, ich bin auch noch ein Bindeglied zwischen User Stories und Testfällen. Dazu werde ich Ihnen aber später noch was erzählen. Recht oft werde ich als Hilfsmittel zum Schneiden von User Stories genutzt. Also, gut … ich gebe zu: Da kann ich manchmal schon recht zickig sein. In diesem Bereich ist der Umgang mit mir nicht ganz so leicht, weil das die Fähigkeit erfordert, die richtigen Fragen zu stellen. Aber ich denke, ich greife schon etwas voraus.

David Holzer: Das ist eine ganze Menge und ich denke, dass diejenigen, die Sie erarbeiten sollen, keine einfache Aufgabe vor sich haben. Wer tut das? Wer erarbeitet Sie?

Akzeptanzkriterium: Kurze Frage, kurze Antwort. Der Product Owner erarbeitet mich hoffentlich gemeinsam und in Abstimmung mit bzw. inspiriert durch die Fragen seines Entwicklungsteams.

David Holzer: Product Owner – ein gutes Stichwort. Ich habe in meiner Recherche für dieses Interview gelesen, dass Akzeptanzkriterien die Erwartungen des Product Owners an eine User Story beschreiben. Stimmt das und wenn ja, was genau ist damit gemeint?

Akzeptanzkriterium: Wer auch immer das geschrieben hat, der trifft den Nagel auf den Kopf: Ich beschreibe die Erwartungen des Product Owners an eine User Story. Das Aufschreiben dieser Erwartungen geschieht aus zwei Gründen: Erstens ist der PO gezwungen, gut darüber nachzudenken, bevor er seine Erwartungshaltungen präzise formulieren kann und wird auf diese Weise zu einer intensiven Vorbereitung gezwungen. Zweitens unterstützen klar formulierte Erwartungen das Entwicklungsteam, den Inhalt der Story wirklich zu verstehen.

David Holzer: Und wann…

Akzeptanzkriterium (unterbricht den Reporter): Entschuldigen Sie bitte, aber das möchte ich noch hinzufügen. Ich bin ein wirklich ruhiger Zeitgenosse und es gibt kaum etwas, was mich aus der Haut fahren lässt. Aber lassen Sie mich noch etwas dazu sagen, weil mir das schon so so so lange auf dem Herzen liegt. Liebe POs da draußen in der Agilen Welt: Ich bin NICHT die Kür! Ich bin die Pflicht, eure Pflicht! Wenn eure Teams mich nicht vorliegen haben, dann ist eure Story unzureichend vorbereitet und kann vom Team abgelehnt werden. Das heißt WAS? Dass eure Priorisierung hinfällig ist und das, meine lieben POs, kostet wiederum Zeit und Kraft und stiftet nur Verwirrung. Niemand verlangt von euch, dass ihr euer Backlog komplett alleine füllen müsst. Ich weiß ja gar nicht, wieso ihr das tut. Um relevante Inhalte über mich zu erhalten, müssen ALLE Beteiligten zusammenarbeiten. Alle! Und das bedeutet, dass man auch über die Story mit allen spricht! So, jetzt geht es mir ein wenig besser.

David Holzer: Kein Problem. Ich denke, dass es wichtig war, dass Sie das noch mal betont haben. Jetzt zu meiner Frage: Wann genau passiert das dann – das Erarbeiten von Akzeptanzkriterien?

Akzeptanzkriterium: Zu zwei unterschiedlichen Zeitpunkten. Die erste gemeinsame Erarbeitung findet im Estimation Meeting statt oder zumindest dann, wenn über User Stories, die dem Entwicklungsteam noch nicht so ganz klar sind, verhandelt wird. Häufig führen die Gespräche über mich dazu, dass User Stories kleiner geschnitten und damit verständlicher für alle werden. Ein tolles Gefühl. (Akzeptanzkriterium strahlt)

David Holzer: Und wann noch? Sie haben von zwei Zeitpunkten gesprochen.

Akzeptanzkriterium: Da ist aber einer ungeduldig (kopfschüttelnd). In den Sprint Plannings natürlich. Im Sprint Planning I komme ich zur Sprache, wenn das Was verhandelt wird. Ich tauche gerne in den Anforderungen auf, aber auch in Constraints oder den Kriterien, die der Product Owner dafür definiert hat, unter welchen Bedingungen er eine Story abnimmt. Und bevor Sie weiter fragen, komme ich natürlich auch im SP2 zur Sprache. Wie sage ich immer: Design ohne Fragen zum Akzeptanzkriterium ist wie Fußball ohne Tor – langweilig und sinnlos. Gut, es soll Leute geben, die finden auch Fußball mit Tor langweilig. Sie nicht auch?

David Holzer: Ich bin eigentlich eher ein Handball-Fan, aber ja, stimmt: Weder Handball noch Fußball sind ohne Tore sonderlich spannend. Aber zurück zu Ihnen: Ich stelle mir das allerdings nicht so einfach vor. WIE geht die Erarbeitung vonstatten?

Akzeptanzkriterium: DAS ist ein wirklich gute Frage. Hier trennt sich die Spreu vom Weizen, was ein gut erarbeitetes Akzeptanzkriterium ist und was eines ist, das keiner versteht oder falsch versteht und dann auch noch falsch umsetzt: Das A und O ist die Vorbereitung des Product Owners. Wenn ich allerdings von guter Vorbereitung spreche, dann meine ich nicht, dass Mr. Product Backlog seinen Katalog an Akzeptanzkriterien im stillen Kämmerlein definiert, dokumentiert und schließlich der Weltöffentlichkeit präsentiert, sondern: Wenn ich eines in den letzten Produktentwicklungsprozessen gelernt habe, dann, dass keine  schriftliche Dokumentation den Wert der verbalen Kommunikation ersetzt. Und damit meine ich NICHT Selbstgespräche, sondern die Kommunikation des PO mit seinem Entwicklungsteam und anderen Product Ownern und Fachleuten und und und. Wenn man mich fragt, WIE man mich am Besten gut und nachvollziehbar erarbeitet, dann sage ich nur drei Worte: Feedback, Feedback, Feedback.

 

Seien Sie auch nächstes Mal wieder dabei, wenn David Holzer das Akzeptanzkriterium fragt:

Wie und womit werden Akzeptanzkriterien erarbeitet?

Welche Fragen muss ich mir als Product Owner und Entwicklungsteam dabei stellen?

Was sind die Merkmale „guter“ Akzeptanzkriterien?


Hier geht es zu Teil 2 des Interviews.