Business Value Poker and more (PO-Tools Nr.3)

Hier der dritte und letzte Teil meines Beitrags zu Product Owner Tools.

Umsetzungsplanung

Nachdem der Kontext eines Produktes definiert ist und ein allgemeines Commitment von allen Beteiligten erreicht wurde, muss die Produktidee umgesetzt werden. Eine detaillierte Zeitplanung im Vorfeld zu erstellen ist in der Regel den Aufwand nicht wert. Man erlangt bessere Ergebnisse, wenn das Team immer wieder neu entscheidet, was der nächste Schritt ist um der Vision ein Stück näher zu kommen anstatt einem festgelegten Plan zu folgen. Dennoch möchte man verschiedene aufeinander aufbauende Ziele definieren und diese in eine zeitliche Abfolge bringen um kommunizieren zu können, was und bis wann möglich sein soll.

Zielorientierte Roadmap

Die Roadmap beschreibt Etappenziele um der Vision näher zu kommen.

Ich zerlege das Big Picture aus der Storymap in kleinstmögliche Pakete, die ein wertvolles Kundenziel abbilden, sogenannte Minimal Viable Products (MVP).

Dazu gehören:

• Die ‘Value proposition’, der Vorteil den man sich erhofft, wenn das Ziel erreicht ist.
• 1-2 überprüfbare Messwerte (KPI), um die Erreichung zu objektivieren.
• Eventuell eine grobe Liste von Tasks, wenn zum besseren Verständnis hilfreich

Für die Abschätzung der Lieferpunkte der MVPs verlasse ich mich nur bedingt auf die Hochrechnung mittels Storypunkten und  Velocity, sondern diskutiere mit den Entwicklern, wie viel Zeit wir uns geben wollen um das jeweilige Ziel zu erreichen.

Im Laufe der Sprints verändert sich die Roadmap durch neue Erkenntnisse und Refokussierung auf den nächst besten Schritt um der Vision näher zu kommen.

Outcome Metriken

Wir verwenden Outcome Metriken im wesentlichen für 2 unterschiedliche Anwendungsfälle.

1. Wir messen, ob wir den erwarteten Wert aus einem Etappenziel auch tatsächlich abschöpfen konnten.
2. Wir messen auf lang- bis mittelfristiger Sicht die Performance des Entwicklung Teams.

Die Art und Weise wie wir Etappenziele überprüfen können, hängt sehr stark von dem jeweiligen Kontext ab.

Hier ein paar Beispiele um das Prinzip zu verdeutlichen.

Ziel:
Wir möchten in der Lage sein, für unser neues Spiel eine “Comeback Mail” an Spieler zu verschicken, die X Tage nicht im Spiel aktiv waren.

Metrik:
Die Churn Rate (Anzahl Spieler, welche das Spiel nicht weiter nutzen, geteilt durch die Summe aller Spieler) sinkt um X %.

Ziel:
Unser Backend soll sich automatisch fehlerhafte Daten nach einem Ausfall aus dem Data Ware House ziehen.

Metrik:
Der Aufwand für manuelle Datenimporte reduziert sich auf X Stunden pro Sprint.

Im Gegenzug dazu sollte man für die Performance Messung möglichst wenige bzw, wenn möglich sogar nur eine Businesskritische KPI definieren auf die man das gesamte Projekt optimiert.

Beispiel: Mittels Email Marketing möchten wir die Retention unsere Spiele langfristig erhöhen.

Die selbe KPI dient auch um Prioritätsentscheidungen zu treffen. Die Priorität wird auf Basis eines Forecast gemacht, die Performance sollte allerdings mit realen Daten gemessen werden. Die Prio KPI sollte deswegen einheitlich sein, damit man auch sehr unterschiedliche Features gegeneinander beurteilen kann.

http://www.startuplessonslearned.com/2013/03/lean-analytics.html

Business Value Poker

Oft ist es schwierig ein Produkt auf eine entscheidende Business KPI runter zu brechen, wie bei dem Beispiel Email Marketing oder bei Inhouse Reporting Tools. Außerdem sind Werte wie Zeitersparnis oder strategische Vorteile oft schwer zu messen bzw. vorherzusagen. In solchen Fällen versuchen ich den Wert von MVPs durch Business Value Poker zu objektivieren. Dabei bewerten wir ähnlich wie im Planning Poker in gemeinsamer Runde die MVPs relativ zueinander. Anstatt mit Entwicklern die Komplexität von Stories in Storypunkten zu schätzen, wird der Business Value von MVPs mit den Stakeholdern relativ zueinander geschätzt.

Da jeder Stakeholder natürlich sein eigenes Thema am wichtigsten und damit am wertvollsten findet, darf er bei der Vorstellung nur inhaltliche Fragen beantworten, aber noch keine Stellungnahme zum Wert abgeben. Dann wird in der Gruppe der übrigen Stakeholder gepokert und diskutiert, um das MVP in der Fibonacci-Skala einzuordnen. Da einigen Stakeholdern das Pokern zu “fancy” ist, orientieren wir uns z.T. auch am Team Estimation Game bzw. ordnen die MVPs einfach gemeinsam in der Skala ein.

Da die MVPs in der Regel noch wesentlich größer sind als die Userstories, verteilen wir die Value-Points anteilig auf die Storys. Die Stakeholder dürfen mitbestimmen, welche Stories den größten Anteil an der Zielerreichung haben.

Genau wie mit Storypunkten kann die Performance des Teams in jedem Sprint mit Value-Punkte gemessen und optimiert werden. Die Value Punkte sind aber in jeden Fall nur ein Workaround, besser ist es eine “harte” KPI für das Produkt zu ermitteln.

Fazit

Die Richtung der Produktentwicklung festzulegen ist eine komplexe Aufgabe für die der Product Owner auf eine große Zahl an Methoden zurückgreifen kann, von denen wir hier einige vorgestellt haben. Dabei ist klar geworden, dass das Einbeziehen von Entwicklungs-Team und Stakeholdern essentiell für den Produkterfolg und für den Verlauf des Projektes ist.

Ich denke, dass es hierbei  notwendig ist, das richtige Verhältnis zwischen klar definierten Zielen und kreativen Lösungsansätze zu finden. Generell sollte jedoch eine konkrete technische Umsetzung niemals Teil einer agilen Planung auf der hier beschrieben Ebene der Produktziele sein. Nur durch flexible taktische Entscheidungen und validiertes Lernen kann man mit jeder Iteration sicherstellen, dass das entstehende Produkt auch zu der initial definierten Produktidee passt.

Wärend der Produktentwicklung ist es notwendig, dass der Produkt Owner das Entwickler-Team immer wieder an der definierten Produktidee und dem erwarteten Outcome ausrichtet. Auch hierfür gibt es eine Vielzahl von Methoden und Praktiken.

Gregor Meyenberg ist Product Owner bei Goodgame Studios