Wer schreibt eigentlich die User Stories?

Der Einsatz von User Stories in der Agilen Softwareentwicklung wird immer populärer. Viele sehen das Verfassen von Benutzergeschichten als Aufgabe des Product Owners – aber wieso eigentlich?

Ich bin der Meinung, dass jeder User Stories erstellen kann. Mike Cohn plädiert sogar dafür, dass alle Projektzugehörigen mindestens eine User Story verfasst haben sollten. Ich verfolge diesen Ansatz auch in meinen Projekten und habe gute Erfahrungen damit machen können. Zwei Anwendungsfälle aus der Praxis möchte ich heute kurz vorstellen.

Im ersten Fall mussten wir bei Start eines Projektes zügig zu ersten User Stories gelangen. Da das Projekt sehr technisch ausgelegt war, waren die Entwickler aus dem Team prädestiniert für das Schreiben der initialen Stories. Also veranstaltete ich mit dem Team und Product Owner einen User Story Workshop. Dieser startete mit den Grundlagen. Daraufhin ging es schnell an das Eingemachte und wir definierten die User Rollen und bestimmten die Ziele.

Anschließend ging es an das Sammeln der Ideen, die im Stil von User Stories aufgeschrieben und den Anwesenden vorgestellt wurden. Schlussendlich konnten wir innerhalb von wenigen Stunden genügend Material zusammenstellen, um anschließend die Stories granularer aufzuschreiben und in das Backlog zu übernehmen. Der Product Owner konnte danach die Priorisierung der User Stories vornehmen, die bei einem weiteren Termin geschätzt wurden.

Lesen Sie hierzu auch den Beitrag von Martin Fowler, der dazu plädiert, dieses Vorgehen grundsätzlich anzuwenden.

Der zweite Anwendungsfall geht noch einen Schritt weiter. Mit Autorisierung des Managements, durfte das entsprechende Team einen kompletten Sprint eigene Ideen umsetzen. Die Durchführung ging jedoch noch einen Schritt weiter – denn jeder schlüpfte in die Rolle des Product Owners.

Der Start war mit der Durchführung eines User Story Workshops identisch – aber ohne Product Owner. In derselben Session wurden daraufhin Ideen gesammelt, die jedes Teammitglied auf Post-its niederschrieb. Nach Vorstellung der einzelnen Ideen durch die Teammitglieder wurden diese priorisiert. Im Anschluss wurden so viele Stories ausgewählt, wie nach Meinung des Teams innerhalb des bevorstehenden Sprints umgesetzt werden konnten. Anschließend wurden die Ideeninhabern dazu aufgefordert, die User Story zu verfassen. Ab diesem Zeitpunkt war jeder „Story Owner“ für seine User Story verantwortlich. Er musste sie erstellen, alles Notwendige klären, im Estimation Meeting sowie Planning Meeting vorstellen und als Ansprechpartner während der Umsetzung zur Verfügung stehen.

Ich muss dazu sagen, dass dieses Team schon eine lange Zeit zusammengearbeitet hat und neben der Selbstorganisation auch mit den Anforderungen des Projekts sehr gut vertraut war. So konnten am Ende eines erfolgreichen Sprints alle Stories dem Product Owner präsentiert werden. Hier ein interessantes Entwickler Statement, welches ich bei dem Review Meeting aufschnappen konnte:

“Besonders spannend an der Übernahme der Product Owner Rolle für einzelne Backlog Items war für mich die Erfahung, wie unterschiedlich der Detailgrad ist, mit dem man aus Produkt- und Entwicklersicht auf die Items schaut. Was aus der ersten Sicht wie vollständig spezifiziert wirkt, kann aus der zweiten Sicht noch viele unbeantwortete Fragen enthalten. Diesen Unterschied hautnah zu erleben ist sicher gut, für meine zukünftige Bewertung von Backlog Items.”

Zum Thema User Stories könnten Sie auch diese Artikel interessieren:

Autor: Robert Wiechmann

Robert Wiechmann arbeitet als Agiler Projektmanager vorrangig in der Rolle als Scrum Master und Kanban Coach. Zu seiner Leidenschaft zählen die Arbeit mit Menschen, insbesondere der Aufbau von produktiven Agilen Teams und die praktische Anwendung von Agilen Softwareentwicklungsmethoden. Zusammen mit Sven Röpstorff verfasste er das Buch Scrum in der Praxis.