Meine Lernreise durch den Advanced Product Owner – Teil 2

Im Teil 1 von diesem Blogbeitrag „Meine Lernreise durch den Advanced Product Owner“ habe ich euch mitgenommen durch die ersten Schritte, die als Product Owner relevant sind auf dem Weg ein Produkt zu entwickeln.

Falls du den ersten Teil noch nicht gelesen hast, spring doch gerne noch rüber. Du kannst aber auch direkt hier starten, wenn du dich mehr für die konkrete Planungs- und Umsetzungsphase interessierst.

Auf in die Planung: Goal-oriented Roadmap

Die Roadmap ist ein Tool, um die Umsetzung der Produktstrategie zu planen und hält vor allem die Antworten auf die Frage „Wie soll sich das Produkt in absehbarer Zeit entwickeln?“ fest. Im Vergleich zum Backlog ist der Zeithorizont weiter, es werden also keine Tasks geplant, sondern den Fokus auf grössere Ziele gelegt. So sehen alle Beteiligten, was geplant ist.

Im Gegensatz zur herkömmlichen Roadmap, die sich auf Funktionen konzentriert, wird in der Goal-oriented Roadmap mit Zielen gearbeitet. Das trägt dazu bei, dass man sich weniger in den Diskussionen um funktionale Features verliert, sondern sich auf grössere gewinnbringende Ziele konzentriert. Die Diskussion verlagert sich also Richtung Wertschöpfung, Investitionsentscheidungen und Abstimmung von Stakeholdern und Entwicklerteam.

Wie funktioniert die Goal-oriented Roadmap?

Die einzelnen Sparten zeigen das nächste Release. Unter Release verstehen wir eine Produktversion, die Mehrwert schafft. Das Release bekommt einen Namen und es werden Ziele formuliert, die beschreiben, warum das Release entwickelt werden soll. Es wird festgelegt, wie gemessen wird, ob das Ziel erreicht wurde. Dabei sind wir beim nächsten wichtigen Punkt: Messbarkeit. Die Ziele müssen messbar sein, sonst wird man nicht sehen, ob das Ziel erreicht wurde.

Wo ist eine zielorientierte Roadmap nützlich?

Bei einem jungen Produkt mit dynamischem Umfeld (neue Wettbewerber kommen laufend hinzu) muss flexibel und kurzfristig auf Änderungen reagiert werden können. Für die Roadmap bedeutet das: kurzer Planungshorizont und häufiges Überprüfen der Roadmap.

Eine featurebasierte Roadmap ist erst sinnvoll, wenn das Produkt sich in einem stabilen Marktumfeld und in der Reifephase des Produktzyklus befindet. Ich kenne meine Nutzer und Käufer gut und muss kaum auf Änderungen reagieren. Da darf der Zeithorizont der Roadmap auch gut 1-2 Jahre betragen,

Wenn es eine interne Roadmap ist, kann man gut fixe Daten angeben. Sobald sie auch extern zur Verfügung steht für Stakeholder, empfiehlt es sich einen Zeitraum anzugeben, um Enttäuschungen vorzubeugen.

Es ist aber ganz wichtig, dass Stakeholder die Ziele der Roadmap mittragen und in die Erarbeitung und regelmässigen Updates einbezogen werden.

Zu sehen ist eine zielorientierte Roadmap als Tabelle. Die fünf linken Spalten zeigen die verschiedenen Eckpunkte. Datum/Zeitraum, Name vom Release, Ziel, Features und Messbarkeit.

Was ist meine Aufgabe als Product Owner?

Die Roadmap soll sich an Vision und Strategie vom Produkt orientieren. Als Product Owner muss ich Entscheidungen in Bezug auf das Produkt treffen und welche Vorschläge umgesetzt werden. Wichtig ist auch den Sinn und Zweck der Roadmap immer im Hinterkopf zu behalten und gegebenenfalls den Stakeholdern immer mal wieder erklären.

Das Erstellen der Roadmap ist relativ zeitaufwendig. 2-4 Stunden sollten dafür eingeplant werden.

Eine bequeme Variante ist die Vorlage von Roman Pichler. Es geht aber auch in gross am Whiteboard mit Post-Its.

Von der Impact- bis zur Story Map

Auf diese Schritte werde ich an dieser Stelle nur kurz eingehen. Falls du tiefer eintauchen möchtest, kannst du das in meinen früheren Blogbeiträgen zu Impact Mapping und Prozessvisualisierung mit Story Maps.

Product Backlog – jetzt wird es konkret

Das Product Backlog ist der zentrale Dreh- und Angelpunkt in der Zusammenarbeit des Produkt-Teams. Und gleichzeitig ist seine Pflege eine der herausforderndsten Arbeiten im agilen Arbeiten.

Die Idee des Backlogs: Eine geordnete Liste von allem, was das Produkt beinhalten und können soll.

Alle Beteiligten, die an der Produktentwicklung arbeiten, haben Zugriff auf das Backlog und haben somit Transparenz, welche Erweiterungen und Änderungen demnächst am Produkt vorgenommen werden sollen. Es ist keine Ideenliste, sondern enthält Massnahmen für das Produkt, die bereits bewertet wurden. Es ist nie vollständig und wird kontinuierlich mit dem Produkt bearbeitet, gepflegt und weiterentwickelt.

Das Product Backlog enthält Einträge, die sogenannten Backlog Items. Items können User Stories, technische Aufgaben, Risiken oder Fehler sein. Sie bestehen aus folgenden Angaben:

  • inhaltliche Beschreibung
  • Angabe zu ihrem Wert
  • Schätzung zum Umsetzungsaufwandes

Alle Items haben eine relative Position zu den anderen Items, durch die das Backlog geordnet wird. Im Backlog konzentriert man sich auf die nächsten Items. Die nächsten anstehenden Items werden genauer beschrieben als die, die erst später umgesetzt werden. Manche Items haben dementsprechend noch keine Angaben zu Wert, Aufwand oder näherem Inhalt.

Durch Feedback zum Produkt wird auch das Backlog weiterentwickelt. Auch Markttrends oder neue Technologien können zu nötigen Änderungen führen.

Das Product Backlog und der Product Owner

Als Product Owner bin ich verantwortlich für den Inhalt des Product Backlog, also die Items und ihre Reihenfolgen. Der Product Owner muss sicherstellen, dass alle relevanten Personen Zugang dazu haben. Einige Aufgaben, wie Backlog Refinement, können delegiert werden, verantwortlich bleibt der Product Owner.

„Refinement“ beschreibt den kontinuierlichen Vorgang, in dem das Team detailliertere Informationen zu den Items hinzufügt. Folgende Aufgaben gehören dazu:

  • Hinzufügen von Details
  • Items in eine angemessene Grösse bringen (z.B. dass das Bearbeiten und Fertigstellen innerhalb eines Sprints realisiert werden kann)
  • Aufwandsschätzungen für Items (Bspw. mit Story Points)
  • Items in eine Reihenfolge bringen

Es gibt keine festgelegte Zeit, wie schnell ein Item das Refinement durchlaufen muss. Die Zeitspanne hängt vom Typ, Kontext, Wichtigkeit und anderen Eigenschaften ab.

Refinement ist ein kontinuierlicher Prozess, an dem der Product Owner und das Entwicklungsteam beteiligt sind. Alle Beteiligten einigen sich auf ein Vorgehen, zum Beispiel auf ein regelmässiges Meeting mit Time Box.

Mit Ordnung zum Ziel

Mehrere Faktoren müssen beachtet werden, um das Backlog zu ordnen:

  • Der Wert der Items muss relativ zueinander abgeschätzt werden (hilfreich dabei: Tools aus der Product Owner Value Chain)
  • Der relative Aufwand eines Items spielt eine Rolle für die Position im Backlog
  • Hilft das Item ein Risiko zu minimieren?
  • Hat es Abhängigkeiten zu anderen Items?

Pro Produkt gibt es ein Backlog. Auch in skalierten Projekten mit mehreren Teams werden die Anforderungen aus demselben Backlog bezogen.

Delivery Kanban

Die Idee eines Kanban ist es, den Arbeitsprozess zu beschreiben und zu steuern, der für die Aufgaben einer Organisation passend ist. Diese Haltung drückt sich in den 4 Prinzipien und 6 Praktiken aus. Diese stellen sicher, dass immer der bestmögliche Prozess durchlaufen wird und alle Beteiligten in die ständige Verbesserung einbezogen sind.

4 Prinzipien

  • Beginne dort, wo du dich befindest.
  • Evolutionäre Veränderung
  • Respekt
  • Führung von allen Ebenen aus

6 Praktiken

  • Visualisere den Arbeitsfluss
  • Begrenze die Arbeit, die gerade getan wird. (Work-In-Progress-Limit WIP)
  • Manage den Fluss
  • Mache Regeln explizit
  • Nutze Feedbackschleifen
  • Verbessere das System kollaborativ

Immer darauf achten, dass sich nicht mehr Items, als das WIP-Limit in einer Spalte befinden.

Zu sehen ist ein Kanban Board mit dem Arbeitsfluss. Abbildung von der nestnormal Academy.

Das Kanban Board visualisiert den Fluss der Arbeit. Spannend für den Product Owner sind vor allem folgende zwei Punkte:

  • Replenishment: Wie viele Tasks können in das Delivery Kanban gegeben werden?
  • Delivery Planning Meeting: Planung, wann die fertiggestellten Items ausgeliefert werden
Zu sehen ist ein Delivery Kanban als Tabelle mit den Spalten Next, Analysis, Developer, Test, Release und Done.

Mein Fazit zum Kurs „Advanced Product Owner”

Für mich war ein grosser Vorteil, dass ich in meinem eigenen Tempo arbeiten und die gelernte Theorie auch direkt im Arbeitsalltag einfliessen lassen konnte. Das Training mit den Aufgaben über oncampus einerseits, andererseits die Anwendung der Tools direkt in Projekten. Hand aufs Herz: für die Aufgaben musste ich mich teilweise echt überwinden. Das fiktive Projekt respektive Produkt im Kurs hat mich nicht ganz so angesprochen. Dafür eine gute Übung auch dranzubleiben, wenn es grad nicht so Spass macht und etwas “harzig” zu erarbeiten ist.

Schreibe einen Kommentar

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

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.