Der Product Owner und seine User Stories

In diesem Artikel möchte mich zuerst mit der Rolle des ProductOwner auseinandersetzen, um aufbauend darauf auf das User Story Mapping zu kommen. Als Praktiker sowohl als ProductOwners als auch als ScrumMaster liegt der klarste Unterschied zwischen den beiden Rollen darin, dass der ProductOwner so etwas wie der „Empiriker“ im Scrumprozess ist. Leider wird gerade dieser Aspekt sehr häufig nicht erkannt, oder sträflich vernachlässigt. Das internationale Verhältnis zwischen den Zertifizierungen (Scrumstudy) liegt in etwa bei ca. 47.000 zerifizierten ScrumMastern und ca. 7.000 ProductOwnern. Ein eigenartiger Zustand, wenn man bedenkt, was ein ProductOwner in Scrum leisten muss und welche Methodenkompetenz er haben sollte.

Die Scrum Factory oder das agile Team

Die Scrum Factory, Kobald Agile Expert & IT-Projects, 2017

Die Rolle des ProductOwner wird häufig unterschätzt. Besonders darin, wie äußerst wichtig es ist, dass im Scrum, aber auch in der Aufbaurganisation verstanden wird, dass der ProductOwner ein Mitglied des agilen Teams ist. Das Team setzt sich aus dem ProductOwner, dem ScrumMaster und dem ScrumTeam zusammen. So weit ich sehe, wird das leider zu oft durchbrochen und der ProductOwner agiert irgendwo und hat nicht wirklich ein klares Verständnis darüber agiles Teammitglied zu sein. Das aber ist meiner Erfahrung nach der erste wichtigste Schritt im ProductOwner Mindset. Denn wie soll ich als ProductOwner die beiden Aufgaben Riskkontrolle und Value-Optimierung erfüllen, wenn ich kein Gespür für den Gesamtzusammenhang habe?

Wie sieht die Realität leider zu oft aus?

Der Product Owner ist für die Erstellung der User Stories, dem User Story Mapping und für das Product Backlog Grooming verantwortlich. Nur wenn diese drei drei Artefakte Ernst genommen werden, kann der Bussiness Value in der Durchlaufzeit eingefahren werden. So weit ich den Markt beobachtet habe, haben derzeit 8 von 10 Unternehmen massive Probleme mit der Velocity und den Lieferumfängen (Menge der Inkremente = Done Increments) in den Sprints. Eine wesentliche Ursache ist meiner Meinung nach darin zu sehen, dass die Wichtigkeit des User Story Mapping durch den ProductOwner eklatant verkannt wird, oder diese Aufgabe vom Product Owner nicht wahrgenommen wird.

Was muss ein Product Owner können?

Ein guter ProductOwner muss jedenfalls eine Ahnung von Requirements Engineering, Stakeholdermanagement und dem Scrumprozess haben. Er ist dafür verantwortlich,

Scrum Rollen
Der ProductOwner ist Teil des ScrumTeams, Kobald Agile Expert & IT-Projects, 2017

dass die Product Vision der gesamten Scrum Factory bekannt ist. Wesentlich erscheint mir die Unterscheidung zum Produktmanager. Ein ProductOwner ist grundsätzlich kein Produktmanager. Natürlich kann ein Produktmanager agilen Team die Rolle des ProductOwner übernehmen. Der ProductOwner ist die Stimme der Business Domains – the voice of the customer! Er hat die Verantwortung dafür, dass die User Stories des Fachbereichs am Product Backlog aufgenommen werden. Nur der ProductOwner darf und soll die User Stories des Product Backlog priorisieren. Dem gegenüber ist der Sprint Backlog in den Händen des Entwicklung-Teams. Hier hat der ProductOwner kein Recht im laufenden Sprint etwas zu ändern. Wenn überhaupt, dann nur in Kooperation mit dem ScrumTeam. Ratsam ist es aber, im laufenden Sprint gar nicht einzugreifen. Umso wichtiger ist es, dass der ProductOwner die Accepance Criterias für die Sprint-Features festlegt. Meiner Erfahrung nach ist es besser, wenn der ProductOwner die User Stories eher im Mindset des Business Analysten als im Mindset des E2E Produkt/Funktionalität/Prozess Spezialisten versteht.

Probleme bei unklarer ProductOwner Rolle

Falls der ProductOwner die User Story Erstellung „schleifen“ lässt, bringt er in den gesamten Scrumprozess in Verzögerung ein. Denn dann werden die Entwickler bei jeder User Story im Planning Meeting diskutieren, weil vieles unklar ist. Oder mitten im Sprint kommt man drauf, dass eine bereits geschätzte User Story noch nicht ganz verstanden ist. Und im worst case wird während des Sprints versucht die User Story Specification nachzuholen. Beides bedeutet unabdingbar, dass die Velocity nicht hält.

User Story Erstellung

Es macht in der Tat einen Riesenunterschied auf welche Art und Weise die User Stories formuliert werden. Arbeitet das ScrumTeam mit dem Behaviour Driven Development Paradigma sind die User Stories ganz anders zu erstellen, als wenn das Entwickler-Team beispielsweise den Test Driven Developement Ansatz wählt. Diesbezüglich ist es unbedingt ratsam, dass sich der ProductOwner beim ScrumTeam schlau macht. So sind 65% der schwerwiegenden Fehler in Programmen auf Fehler beim Requirements Engineering zurückzuführen. User Stories sollen einfach, klar und unmissverständlich sein. Ein Beispiel:  Als Benutzer einer Oberfläche, der einen Onlinekurs gebucht hat, möchte ich mich einloggen, sodass ich meine Buchungsdetails bearbeiten kann. Meiner Erfahrung nach sollte zu jeder Epic die in mehrere User Stories aufgeteilt werden muss, eine derartige kurze und klare User Story verfasst werden.

User Story Writing Workshop

Im Idealfall startet jedes Scrum-Projekt mit einem User Story Writing Workshop. Dabei geht es darum in einem kollaborativen Setting ein gemeinsames Verständnis der User Stories herzustellen. Dem ScrumTeam wird ermöglicht, die Art und Weise der User Stories kennenzulernen, diese zu aktzeptieren und ein gutes Gefühl für die Planning Poker zu entwickeln.

User Story Writing Workshop, Kobald Agile Expert & IT-Projects, 2017

Der Ablauf sollte folgender sein:

  1. Fokusierung auf eine größere User Story, die mehrere Sprints benötigt, um fertig zu werden.
  2. Die richtigen Teilnehmer dabei haben: Entwickler, Tester, UX-Designer, Fachbereichsvertreter, ScrumMaster, Architekt, Business Analyst
  3. Die große Story (Epic) gemeinsam auf kleinere Stories herunterbrechen
  4. Auf einem Witheboard mit Sticky Notes den Zusammenhang der Stories chronolgisch darstellen
  5. Zuerst Konzentration auf das Minimum Viable Product (MVP) und Minimum Marktable Feature (MMF)
  6. User Story Struktur: Als eine <Rolle>, möchte ich <einen bestimmten Nutzen>, mit dem <Ergebnis> erreichen.