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:

• Der Unterschied zwischen User Story und Use Case wird Ihnen klarer, wenn sie diesen Artikel lesen.
• Erstmalig fanden die User Stories mit dem Extreme Programming (XP) ihre Anwendung.
• Traditionelle Anforderungen, Use Cases oder doch User Stories – eine Meinung.
• Wie modelliert man eine User Story?
• User Stories für das Product Backlog einsetzen (Teil 1 & Teil 2)

Über den Autor

Momentan als Projektmanager und Agiler Coach in Hamburg tätig, unterstütze ich Scrum und Kanban Teams bei der Bewältigung ihrer alltäglichen Herausforderungen. Zudem bin ich mit dem Coaching von Mitarbeitern betraut und laufend bestrebt, in den Austausch mit Anwendern agiler Methoden zu treten.