Agile / Anforderungsmanagement

Der Product Owner: das Gehirn des Scrum Frameworks! 2/3

„Ok, um anfangen zu können brauchen wir jetzt Use Cases oder User Stories, der Project Owner soll die jetzt schreiben, kann ja nicht so schwer sein“. Ist Ihnen etwas an dieser Aussage aufgefallen? Diese Aussage ist eine Falschaussage. Das einzig Richtige ist, dass Anforderungen benötigt werden, um mit der Entwicklung zu beginnen. Leider klingen Use Cases so ähnlich wie User Stories, oder auch nicht. In der Praxis werden sie gerne synonym verwendet. Auch höre ich immer wieder den sogenannten Project Owner. Ein freudscher Versprecher oder gar eine Hybridrolle? Die Antwort ist simpel: das Verständnis für diese Rolle fehlt noch bzw. hat sich noch nicht etabliert. Mehr zur Rolle des Product Owners ist auch in Teil 1 dieser Blogreihe zu lesen.

Product Owner_User Stories_Use Cases

User Stories! = Use Cases

Aber fokussieren wir uns jetzt einmal auf die Nomenklatur „User Story“ bzw. „Use Case“. Ein Use Case beschreibt einen Anwendungsfall. Am häufigsten wird der UML Standard verwendet. Meistens gibt es ein Use Case Diagramm, das einen Prozess anhand eines Szenarios beschreibt. Jeder Schritt sollte hierbei konkretisiert werden. Wie man sich vorstellen kann, könnte dieser Use Case enorm groß werden. In der Praxis bricht man diese Use Cases in weitere Einzelszenarien herunter, jedoch ist nicht gesagt, dass diese eine technische Umsetzungsmöglichkeit im Hinterkopf haben.

Es wird dabei nicht darauf geachtet, ob diese Use Cases unabhängig voneinander funktionieren oder nicht. Auch wird nicht darauf geachtet, dass seitens Software Architektur ein vertikaler Schnitt durch alle Ebenen erfolgt, sodass die Teilsoftware alleinig geliefert werden kann. Diese Faktoren werden bei einer User Stories sehr wohl beachtet. Nehmen wir als Beispiel das Szenario „Login“. Ein Login kann unterschiedlich interpretiert werden, ein Use Case beschreibt anhand eines Diagramms den Prozess wie ein Login funktioniert. Nicht mehr und nicht weniger. Ein Akteur loggt sich ein, kann dabei auch ein „Passwort vergessen“ abfragen. In der Regel hat er aber einen Username und ein Passwort mit denen er sich im gewünschten Szenario im System einloggt. Diese Beschreibung ist eher allgemein und funktional beschrieben. Eine User Story geht darüber hinaus. Dieser Use Case kann als Basis verwendet werden, aber im Endeffekt werden viel mehr User Stories daraus entstehen, da hierbei wirklich das Agieren des Users beschrieben wird. Normalfälle, Fehlerfälle und Sonderfälle werden ebenfalls miteinbezogen. Auch z.B. eine Mehrsprachigkeit kommt in diesem Use Case nicht heraus, was eine eigene User Story sein könnte.

Der Product Owner hat also die Aufgabe für jeden Beteiligten, sei es jetzt Entwickler, Tester oder sogar Außenstehender, eine User Story so zu beschreiben, dass sie verständlich, unabhängig zu anderen und end to end testbar ist.

 

Die Macht der User Stories

Und das ist das Tückische an einer User Story. Der Aufbau laut Definition ist immer der Gleiche: „Als <Rolle> möchte ich <Funktionalität>, um <Nutzen> zu generieren.“ Dazu müssen für die Abnahme aber auch noch sogenannte Abnahmekriterien verfasst werden. Klingt simpel oder? Ist es aber nicht. Wie oben erwähnt, alle im Umsetzungsteam oder sogar noch darüber hinaus müssen die User Story verstehen und auch umsetzen können. Dies erfordert in der Erstellung viel mehr Denkarbeit als es zunächst erscheint. Um beim obigen Beispiel zu bleiben, im letzten Projekt hat bei mir das Epic „Login“ ca. 8 User Stories benötigt bis es produktiv gesetzt wurde. Im Zuge des Schreibens wird einem klar, wie viele „Kleinigkeiten“ plötzlich auftauchen, mit denen man vorher nicht gerechnet hat. Auf diese Punkte kommt der Product Owner unter Umständen nicht alleine. Diese Erkenntnis liegt aber einem wichtigen Fakt zu Grunde: dem Estimation Meeting. User Stories werden, wie einleitend schon beschrieben, vom Product Owner verfasst.

Er hat einen gewissen Blickwinkel auf seine Anforderungen. Das ist auch gut so. Der Product Owner hängt diese geschrieben User Stories dann in seinen Backlog, sprich Auffangbecken für seine gesamten Anforderungen, und priorisiert diese letztendlich. Mit den höchst priorisierten Stories geht er ins Estimation Meeting. Dort werden zum ersten Mal die „Geschichten“ den Teammitgliedern erzählt. Spätestens hier kommt die erste Feuerprobe für den Product Owner. Auf Grund der Inhalte der Stories schätzen die Teammitglieder anhand von Story Points dessen Umfang, Klarheit, Risiken und Komplexität. Bei eingespielten Teams und guten Product Ownern geht das Estimation Meeting – timeboxed, relativ straigt forward –  von statten.

 

Anforderungen verstehen und klar umsetzen steigert die Qualität

Falls der Product Owner seine Aufgaben nicht ernst nimmt, zu wenig Erfahrung im Schreiben von User Stories hat oder es nicht gewohnt ist so detaillierte End-to-End Abnahmekriterien zu formulieren, kann ein Estimation Meeting in einem Desaster enden oder durch den Scrum Master abgebrochen werden. Das Resultat: der Scrum Master (oder das ganze Team) bittet den Product Owner die Stories erneut zu schreiben oder soweit abzuändern, dass es dem Team auch möglich ist sie letztendlich zu schätzen bzw. umzusetzen.

Natürlich kann es vorkommen, dass Stories, die sehr groß geschätzt wurden (bei mir sind es in der Regel ab 13-100 Story Points) in den Backlog zurückwandern. Da sie nicht in einem Sprint umgesetzt werden können, muss sie der Product Owner überarbeiten. Konkret bedeutet dies: verständlicher schreiben, mehr Details hinzufügen oder kleiner schneiden. Was man hierbei nicht vergessen darf, der Product Owner ist letztendlich dafür verantwortlich, dass das Team seine Anforderungen versteht und auch umsetzt. Dies sollte eigentlich innerhalb eines Sprints ohne größere Rückfragen möglich sein. Es erspart dem Product Owner auch viel Arbeit in der Abnahme am Ende des Sprints bzw. auch beim Vorstellen der umgesetzten Teile im Review, weil die Anforderungen in Form von User Stories vor dem jeweiligen Sprint extrem detailliert ausspezifiziert wurden. Dabei gibt es immer vom gesamten Team ein Commitment. Es werden die User Stories umgesetzt, die am Anfang eines Sprints (dieser kann 2 oder 4 Wochen lang sein), gemeinsam gewählt wurden.

Jetzt fragen sich vielleicht einige: „Aber, wenn sie vorher definiert wurde, wo ist dann der Mehrwert vom agilen Vorgehen und User Stories“. Der Mehrwert liegt definitiv an den kurzen Zyklen. Innerhalb der 2 oder 4 Wochen ändern sich die Anforderungen nicht mehr, sehr wohl können sich aber die User Stories im Backlog ändern, repriorisiert werden, wegfallen oder neue dazukommen. Darin liegt die Stärke des Scrum Frameworks. Der Product Owner hat einen großen Spielraum Anforderungen zu ändern, nur in den 2 oder 4 Umsetzungswochen sind sie fixiert. Natürlich kann es schon einmal vorkommen, dass innerhalb eines 2-wöchigen Sprints User Stories innerhalb der Umsetzung obsolet werden. Dann hat man aber nur 2 Wochen verloren und nicht wie bei einem klassischen Vorgehen unter Umständen ein halbes Jahr oder mehr. In diesen Szenarien werden auch die klassischen Change Requests nicht mehr benötigt. Durch die Priorisierungen ergibt sich eine natürliche Reihenfolge und in ein volles Glas geht nicht mehr hinein. So fallen die Stories mit dem niedrigsten Ranking raus.

Dies ist nun das Ende von Teil 2/3. Ich hoffe Sie haben einen guten Überblick über das Instrument, die User Stories und deren Wichtigkeit sowie über die Aufgabe des Product Owners bekommen. In Teil 3 widmen wir uns noch dem Berufsbild des Product Owners.

 

 

Blogreihe:

Der Product Owner: das Gehirn des Scrum Frameworks! 1/3 – Rolle
Der Product Owner: das Gehirn des Scrum Frameworks! 2/3 – User Stories

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*