User Stories stellen die Basis des agilen Requirements Engineering dar. Gute User Stories sollten verhandelbar sein. Doch was hat es damit auf sich? Wer verhandelt mit wem? Warum hilft das? Und wie erstellt man als Product Owner verhandelbare User Stories?
Anders als im klassischen Anforderungsmanagement stellt eine User Story keine vollständige Spezifikation einer Anforderung dar, die nur noch implementiert werden muss. Viel eher ist eine User Story ein Versprechen des Product Owners, mit dem Entwicklungsteam über die Anforderung zu sprechen bzw. zu verhandeln. Inhalt dieser Verhandlung ist, wie die Anforderung konkret durch das Entwicklungsteam umgesetzt werden kann. So ist sichergestellt, dass die Anforderung zur Zufriedenheit des Product Owners mit dem geringsten Aufwand umgesetzt wird. Es geht nicht darum, zu verhandeln, ob die Anforderung überhaupt umgesetzt werden soll.
Wenn die Diskussion über die Umsetzung einer User Story zwischen dem Product Owner und dem Entwicklungsteam schwierig zu führen ist, dann liegt das häufig daran, dass die User Story nicht verhandelbar formuliert ist. In meinen Trainings zum agilen Requirements Engineering nutze ich folgende Übung, um den Teilnehmenden den Unterschied zwischen einer verhandelbaren und einer nicht verhandelbaren User Story zu verdeutlichen:
Auf dem Tisch liegen verschiedenfarbige Stifte. Jeder bekommt ein leeres DIN A4 Blatt und eine "User Story". Die Aufforderung an die Teilnehmenden ist, die Aufgabe zu lesen und innerhalb von fünf Minuten das zu malen, was dort beschrieben ist. Es gibt zwei verschiedene Arten der "User Story":
User Story A: Malt ein Quadrat. Darüber ein Dreieck. In dem Quadrat sollen rechteckige Löcher sein. Im Dreieck ein kreisrundes Loch. Rechts daneben ist ein Zylinder, auf dem oben ein Kreis positioniert ist. Umgeben ist alles von einer Begrenzung. Die Elemente sollen farbig sein.
User Story B: Malt ein Haus mit Garten.
Das Schöne an dieser Übung ist, dass es kein Richtig und kein Falsch gibt. Jeder malt das, was er darunter versteht und wie er es kann. Und egal, wie gut die malerischen Fähigkeiten der Teilnehmenden sind, gibt es einen deutlichen Unterschied zwischen den Ergebnissen der beiden Gruppen. Warum ist das so?
In der User Story A wurde versucht, möglichst genau zu beschreiben, wie das Haus mit Garten gemalt werden soll. Allerdings ist weder der Kontext noch der Nutzen klar. Daher können die Teilnehmenden keine Verständnisfragen stellen, sondern versuchen einfach, so genau wie möglich die User Story zu erfüllen.
In der User Story B wurde das erwartete Ergebnis formuliert. Da die Teilnehmenden nur eine begrenzte Zeit zur Verfügung haben, fängt sofort die Diskussion über den Umfang an: Ist in dem Garten ein Baum?, Werden Blumen benötigt?, Wie viele Fenster soll das Haus haben? usw. Denn davon hängt der Aufwand für die Umsetzung ab. In der Übung sieht man daher bereits in der Arbeitsphase ein deutlich anderes Vorgehen zwischen den Gruppen. Bei der Gruppe B ergibt sich automatisch eine intensivere Diskussion über die Inhalte. Da der Gruppe B der Kontext der Anforderung klar ist, werden ihre Ergebnisse immer besser der eigentlichen Anforderung genügen als die Ergebnisse der Gruppe A.
Bei beiden User Stories ist das eigentliche Ziel, ein Haus mit Garten zu malen. Der Hauptunterschied ist, dass User Story A möglichst detailliert versucht, die Lösung zu beschreiben, wohingegen User Story B das Problem beschreibt. Natürlich ist dieses Beispiel ziemlich plakativ und vereinfacht. Aber ich bekomme oft zu hören, dass der Product Owner viel Arbeit in die User Story investiert hat, so dass die Anforderung doch eigentlich für alle verständlich sein muss. Alle Details sind beschrieben. Das Problem ist dann häufig, dass der Product Owner versucht, möglichst detailliert seine Lösung des Problems zu beschreiben, aber nicht das Problem selbst, das gelöst werden soll.
Die Antwort auf die Ausgangsfrage "Wie kann der Product Owner verhandelbare User Stories erstellen?" ist, dass er sich in den User Stories auf die Formulierung des Problems konzentriert. Die Lösung bzw. Umsetzung sollte zusammen mit dem Entwicklungsteam verhandelt werden, nachdem es das Problem verstanden hat. Das Ergebnis dieser Verhandlung sollte dann unbedingt Teil der User Story werden, so dass alle Beteiligten das gleiche Verständnis haben. An der Übung sieht man, dass die Ergebnisse bei diesem Vorgehen besser sein werden.
Wir bieten individuelle Trainings zum agilen Requirements Engineering an. Bei Interesse einfach eine Mail an workshops@neuland-bfi.de schreiben. Weitere Informationen und zusätzliche Angebote gibt es auch auf unserer Seite der agilen Coaches bei neuland.
Ist seit 2011 bei neuland. Sein Steckenpferd ist agiles Requirements Engineering und alles, was mit agilem Arbeiten zu tun hat. Wenn er gerade mal nicht das Douglas Team unterstützt, moderiert er Retrospektiven oder führt Trainings zum agilen Arbeiten durch.
