Share ZU:
16 October 2019 @ Samuel Harder

Eine einzige Technik – für erfolgreiche Product Owner in Scrum

Als Produkt Owner machst du ein klares Versprechen: Dem Kunde ein hochwertiges Produkt zu liefern. Simpel, könnte man denken. Vor allem, da dieses Versprechen in Scrum durch eine einzige formale Verantwortung abgebildet wird: den Backlog.

Doch die Schlüsselfunktion des Product Backlogs verlangt es, Informationen und Expertise aus allen Ebenen der Produktentwicklung zu vereinen. 
Hier den Überblick zu behalten ist nahezu unmöglich. Während du einerseits Stakeholder identifizierst, musst du auf der anderen Seite Auswirkungen zunächst rein technischer Details verstehen. Und wenn du mit Kunden redest, musst du deren Bedürfnisse so abbilden, dass dein Team deine Annahmen über den Markt testen und weiterentwickeln kann. Ein fast unmöglicher Spagat.

Product Owner und User Story Mapping

Hier schon mal mein persönlicher Tipp: Ähnlich wie „das Fräulein vom Amt“ in einer historischen Telefonzentrale solltest sichergehen, dass Informationen nicht bei dir verharren, sondern richtig weitergeleitet werden. Jede Information, die bei dir bleibt, stirbt in dir und mit ihr das Produkt. Damit also genau das nicht passiert solltest du User Story Mapping verwenden. Wer ruft schon heut zu Tage noch bei der Auskunft an…

User Story Mapping ist eine Technik, um ein gemeinsames Verständnis zu erzeugen. Dabei arbeiten alle Produktbeteiligten zusammen an der Frage: „Welche Aktivitäten muss ein Nutzer durchführen, um sein Ziel zu erreichen?“ Spätestens hierbei wird allen Beteiligten der unumgängliche Dreh- und Angelpunkt des Produkts klar: Der Kunde.
Im nächsten Schritt wird jede Aktivität des guten alten Flussdiagramms um die Weiterentwicklungen ergänzt, welche es dem Nutzer erleichtern sein/ihr Ziel zu erreichen.

Und genau hier beginnt die Magie: unter deiner Führung bringen alle Beteiligten vom Entwickler über den User Research Experten bis hin zum Stakeholder ihre Expertise und Information ein und finden gemeinsam heraus, wo welche Weiterentwicklung der sogenannten User Journey am meisten Sinn macht. So integriert User Story Mapping die Expertise aller Produkt-Beteiligten, ohne dass du zwischen Einzelpersonen vermitteln musst. Solange du einen immer wieder einen gemeinsamen Focus herstellst werden deine Anforderungen ganz von allein besser als du es dir jemals erträumt hättest.

Aus dem Buch: “User Story Mapping: Discover the Whole Story, Build the Right Product “, von Jeff Patton

Darstellung im Detail

Im Detail: Auf einer horizontalen Achse werden die Aktivitäten abgetragen, die ein Nutzer durchführen muss, um einen erwünschten Zweck zu erfüllen. Um die Story deiner User wortwörtlich zu erzählen kannst du diese Aktivitäten mit „und als nächstes“ oder „alternativ“ verbinden.

Während diese Darstellung dich zwingt genau dem Nutzer zu folgen, bietet sie den User Experience Experten die perfekte Vorlage, um Mockups oder Änderungen am Produkt mit den Nutzern zu testen.

Die User Stories unter den jeweiligen Aktivitäten sind die Details, die vom Nutzer durchgeführt werden müssen oder können, um sein/ihr Ziel zu erreichen. Deren vertikale Anordnung unter den Aktivitäten stellt ein Ranking dar. Die unverzichtbaren Stories stehen weiter oben, eventuelle Ausbaustufen folgen. Durch diese Darstellung mehrerer Release-Iterationen bringt dich User Story Mapping sofort in Architektur-Überlegungen mit dem Developement Team. Dies hilft dabei vorausschauend zu planen und ungewollte technische Schuld zu vermeiden.

Fazit:

User Story Mapping hilft dir alle Veränderungen für einen bestimmten Use Case oder gar eins ganzen Produkts vollständig zu erfassen und bringt alle Beteiligten in eine konstruktive Diskussion. Sobald eine Person vor einer User Story Map steht wird klar, dass alle Interessen in ein komplexes Netz eingebettet sind und nicht unabhängig voneinander erfüllt werden können.

User Story Mapping hat mindestens drei große Vorteile:

Verständnis Gemeinsame
Lösungsfindung
Informations-
fluss
Information aller Seiten
sind verfügbar und verschiedene Sichtweisen sind einfach verständlich.
Jedes Teammitglied ist befähigt Lösungsvorschläge einzubringen . Der Product Owner wird nicht zum Informationsengpass.