Suche
Essenzielle ökonomische Werkzeuge für agiles Produktmanagement

Die Product Owner Toolbox

Gerrit Beine

@istock/Young_school_teacher_Halfpointo

Das erste der zwölf Prinzipien hinter dem agilen Manifest lautet: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen“. Während viele Teams Best Practices durch die frühe und kontinuierliche Auslieferung kennen und auch anwenden, ist die Bestimmung, was wertvolle Software ist, oft nicht so trivial.

Gerade der Product Owner muss aber wissen, ob die Software der Vorstellung seines Kunden von „wertvoll“ entspricht. Dazu gibt es etliche Methoden, die allerdings bisher keinen Eingang in das übliche Curriculum der Product-Owner-Zertifizierung gefunden haben.

Keine Software ohne Nutzen

Software zu entwickeln ist für Unternehmen kein Selbstzweck. Die Entwicklung von Software wird als teuer empfunden, auch wenn Tom DeMarco diese Gefühle seit vielen Jahren kritisch hinterfragt [1]. Also muss die zu entwickelnde Software einen möglichst großen Nutzen haben. In der Regel wird dieser Nutzen vor der Entwicklung durch einen Business Case beschrieben, in dem Kosten und Nutzen für das Unternehmen betrachtet und auf dessen Grundlage entschieden werden kann, ob das Projekt durchgeführt wird oder nicht.

Leider kommt es viel zu häufig vor, dass der Business Case die einzige ökonomische Bewertung eines solchen Projekts bleibt. Projekthäuser verfolgen zwar in der Regel den Earned Value bei Festpreisprojekten, aber dieser steht mit dem Wert der Software in keinem Zusammenhang. Vor allem agiles Projektmanagement erlaubt es, die ökonomische Betrachtung des Business Case auf einzelne Aspekte eines Projekts herunterzubrechen und immer wieder neu zu bewerten. Backlog Grooming muss sich nicht nur auf die fachlichen Aspekte von User Stories beschränken, sondern kann auch mit betriebswirtschaftlicher Brille erfolgen.

In seinem Video „Agile Product Ownership in a Nutshell“ hat Henrik Kniberg schön illustriert, wie eine Wertschöpfungskurve in einem agilen Projekt aussehen kann (Abb. 1). Zunächst liegt der Schwerpunkt auf dem Wissenszuwachs im Team. Der Zeitraum sollte möglichst kurz sein, um schnell maximalen Kundennutzen zu generieren.

Abb. 1: Wertschöpfungskurve in einem agilen Projekt; für kurze Zeit liegt der Schwerpunkt auf dem Wissensgewinn für das Team, danach auf der Schaffung von Wert für den Kunden; Quelle: Henrik Kniberg: „Agile Product Ownership in a Nutshell“ [3]

Abb. 1: Wertschöpfungskurve in einem agilen Projekt; für kurze Zeit liegt der Schwerpunkt auf dem Wissensgewinn für das Team, danach auf der Schaffung von Wert für den Kunden; Quelle: Henrik Kniberg: „Agile Product Ownership in a Nutshell

Aber wie muss das Backlog priorisiert werden, damit eine solche Kurve erreicht werden kann? Die Basis dafür lässt sich in einer trivialen Formel ausdrücken (Abb. 2).

Abb. 2: Formel für eine Wertschöpfungskurve in einem agilen Projekt

Abb. 2: Formel für eine Wertschöpfungskurve in einem agilen Projekt

Die Bewertung der einzelnen Backlog Items kann dabei mit verschiedenen Modellen geschehen.

Junior Product Owner: Return on Investment

Return on Investment, oder auch kurz RoI, ist mit Sicherheit die bekannteste betriebswirtschaftliche Kennzahl. Was allerdings weniger bekannt ist: Vom RoI gibt es zwei Varianten: Bei der ursprünglichen Variante des RoI handelt es sich um eine Kennzahl, die an der Spitze der DuPont-Kennzahlenpyramide steht und die Rendite einer unternehmerischen Tätigkeit betrachtet. Dabei fließen alle betriebswirtschaftlichen Daten aus dem Unternehmen ein – Fremdkapital, Umsatzrendite, liquide Mittel, Zinsen und jede Quittung. Dieser RoI kann nur a posteriori ermittelt werden und ist für die Bewertung eines Investments in ein Unternehmen sinnvoll. Für die Tätigkeit eines Product Owners taugt er wenig. Die Variante, die die meisten Menschen meinen, wenn sie von RoI sprechen, ist die zur Beurteilung von Einzelentscheidungen. Diese wird normalerweise im Vorfeld ermittelt und kann mit einer kompakten Formel (Abb. 3) ausgedrückt werden. Alle weiteren Ausführungen beziehen sich auf diese Variante des RoI.

Abb. 3: Formel zur Beurteilung von Einzelentscheidungen

Abb. 3: Formel zur Beurteilung von Einzelentscheidungen

Allgemein gilt: Je größer der RoI, desto besser. Natürlich lassen sich Gewinn und Investition im Vorfeld nur schätzen. Aber allein die Beschäftigung mit dem möglichen Gewinn aus einem unternehmerischen Vorhaben führt häufig schon zu interessanten Erkenntnissen.

Leider hat der RoI einige signifikante Schwächen, weshalb er für Product Owner als Einsteigerlevel gelten muss. Die wichtigste dieser Schwächen ist der fehlende Zeitbezug. Der RoI betrachtet nicht, dass Geld im Laufe der Zeit an Wert verliert. Ein Euro, den man heute durch die Software verdient, ist mehr wert, als ein Euro, der erst morgen verdient wird. Wird eine Bewertung von Backlog Items anhand ihres RoI durchgeführt, kann es sein, dass Backlog Items, die erst relativ spät realisiert werden, einen positiven RoI haben, obwohl ihre Realisierung tatsächlich einen Verlust bedeutet.

Interessanterweise beschränken viele Unternehmen ihre Investitionsentscheidungen für Business Cases auf eine Betrachtung des RoI. Der Grund ist gleichzeitig der entscheidende Vorteil des RoI: Er ist leicht und schnell berechnet, und die Schätzung beschränkt sich auf zwei Werte. Für Product Owner ist der RoI praktisch gesehen untauglich. Eine Priorisierung auf Basis des RoI ist aber immer noch besser, als Backlog Items gar nicht ökonomisch zu betrachten.

Senior Product Owner: Net Present Value

Um die größte Schwäche des RoI auszumerzen, sind bei der Betrachtung von Gewinn und Investition die Zeit und der mit ihr einhergehende Wertverlust des Gelds zu berücksichtigen. Das betriebswirtschaftliche Werkzeug dazu ist der Net Present Value oder auch NPV.

Die Idee des Net Present Value lässt sich vereinfacht so beschreiben: Alle Gewinne und Investitionen werden als Summe von Cashflows zu verschiedenen Zeitpunkten betrachtet. Die Cashflows werden entsprechend des Zeitpunkts, zu dem sie stattfinden, mit dem prognostiziertem Zinssatz diskontiert. Damit werden Cashflows, selbst wenn die Menge des Gelds identisch ist, hinsichtlich ihres Werts so korrigiert, dass eine realistischere ökonomische Betrachtung als durch den RoI erfolgen kann. r ist in der zugehörigen Formel (Abb. 4) der Zins, mit dem der Geldwert sich pro Periode verringert und n die Anzahl der Perioden, über die der NPV ermittelt werden soll.

Abb. 4: Formel zur Berechnung des Net Present Value

Abb. 4: Formel zur Berechnung des Net Present Value

Üblicherweise ist das der Zeitraum, in dem die Software genutzt werden soll. Während die Werte für n und r normalerweise feststehen, müssen die Cashflows wiederum geschätzt werden. Das lässt sich je nach Business Case mehr oder weniger genau machen. Für die neue Software eines Start-ups lassen sich die zukünftigen Cashflows weniger präzise vorhersagen als für die Einsparungen, die durch eine intern eingesetzte Software in einem Konzern möglich sind.

Abbildung 5 zeigt ein einfaches Beispiel für solch eine NPV-Betrachtung. Ein Euro, den man heute durch die Software verdient, ist einen Euro wert. Morgen verdienen Unternehmen mit der Software auch noch einen Euro, aber dessen realer Wert ist nur noch 95 Cent.

Abb. 5: Einfaches Beispiel für Net Present Value: Nach der Investition wird durch eine Software ein positiver Cashflow erzeugt; dieser ist nominal konstant, wird aber durch Verzinsung des Gelds real mit jeder Periode weniger Wert

Abb. 5: Einfaches Beispiel für Net Present Value: Nach der Investition wird durch eine Software ein positiver Cashflow erzeugt; dieser ist nominal konstant, wird aber durch Verzinsung des Gelds real mit jeder Periode weniger Wert

Der Vorteil gegenüber dem RoI liegt auf der Hand: Weil der Wert des Gewinns zu einem konkreten Zeitpunkt berücksichtig wird, kann es nicht passieren, dass Backlog Items realisiert werden, obwohl ihr realer Wertbeitrag negativ ist. Ein Backlog Item, das erst spät realisiert wird und deshalb auch erst spät zur Wertschöpfung beiträgt, wird nur dann realisiert, wenn dieser Wertbeitrag zu diesem Zeitpunkt positiv ist. Das kann beim RoI durchaus der Fall sein, während der NPV die Wahrheit offenbart.

Auch wenn der NPV dem RoI überlegen ist, hat er Schwächen, die ein Product Owner bei seiner Anwendung kennen muss. Der NPV liefert eine genauere Wertbetrachtung als der RoI, aber beiden gemeinsam ist, dass sie jeweils nur ein Szenario betrachten. Zur Entscheidung für oder gegen ein Backlog Item ist der NPV eine hervorragende Methode. Bei einer Priorisierung mit dem NPV besteht nicht die Gefahr, dass Backlog Items zu einem Zeitpunkt realisiert werden, zu dem sie keinen Wertbeitrag mehr liefern, wie es beim RoI der Fall sein kann. Schwierig wird der Einsatz des NPV auch in Bereichen, in dem eine Betrachtung des Wertbeitrags als Cashflow nicht oder nur unvollständig möglich ist.

Tatsächlich ist der NPV für die meisten agilen Projekte aber ausreichend und gehört definitiv in den Werkzeugkoffer eines jeden Product Owners.

Chief Product Owner: Cost of Delay

Die umfassendste und genauste Betrachtung des Werts von Backlog Items sind die Costs of Delay oder auch CoD, die Donald G. Reinertsen [2] beschreibt. Die Idee der CoD geht in eine völlig andere Richtung als die Betrachtung der RoI oder des NPV. Bei der Ermittlung der CoD steht nicht die Frage im Vordergrund, wie hoch der Gewinn aus dem Wertbeitrag eines Backlog Items ist, sondern wie viel Wertbeitrag nicht geleistet wird, wenn dieses Backlog Item später oder gar nicht realisiert wird. Erfahrungsgemäß fällt es vielen Menschen zunächst schwer, sich auf ein solches Gedankenmodell einzulassen. Es ist aber extrem hilfreich, denn die CoD reichen viel weiter als es eine bloße Betrachtung des NPV jemals könnte.

In die CoD können viele verschiedene Aspekte einfließen. Eine einfache Vorstellung lässt sich aber auf Basis des NPV vermitteln. Der NPV liefert den Wert eines Backlog Items, wenn dieses zu einem definierten Zeitpunkt realisiert wird. Verschiebt sich dieser Zeitpunkt nach hinten, wird der erste Cashflow natürlich ebenfalls später eintreten und muss um den entsprechenden Wertverlust reduziert werden. Das Gleiche gilt für alle folgenden Cashflows, sodass der NPV insgesamt niedriger wird. Die Differenz zwischen dem NPV für eine Realisierung heute und dem NPV für eine spätere Realisierung sind die Costs of Delay.

Dieses Modell ist natürlich stark vereinfacht. Praktisch gehören in die CoD noch viele andere Aspekte, die Donald G. Reinertsen ausführlich beschreibt. Darstellen lassen sich die CoD leicht durch „Urgency Profiles“, wie sie Joshua J. Arnold verwendet. Drei davon sind in den Abbildungen 3 bis 5 dargestellt. Die blaue Linie zeigt jeweils den Gewinn aus einem Backlog Item, wenn es heute realisiert würde, die orangefarbene Linie zeigt die Gewinnkurve, wenn das Backlog Item später realisiert wird. Die grauen Flächen dazwischen sind jeweils die CoD. Für unterschiedliche Szenarien können unterschiedlich hohe CoD entstehen. Im ungünstigsten Fall, wie in Abbildung 5 dargestellt, sind sie sogar unbegrenzt.

Abb. 6: Urgency Profile für ein Projekt mit kurzem Amortisationszeitraum; durch die verspätete Realisierung geht Geld sowohl durch den verzögerten Markteintritt verloren als auch durch das Nichtausschöpfen des Peaks; Quelle: Joshua J. Arnold: „Urgency Profiles“ [5]

Abb. 6: Urgency Profile für ein Projekt mit kurzem Amortisationszeitraum; durch die verspätete Realisierung geht Geld sowohl durch den verzögerten Markteintritt verloren als auch durch das Nichtausschöpfen des Peaks; Quelle: Joshua J. Arnold: „Urgency Profiles“

Abb. 7: Urgency Profile für ein Projekt mit langem Amortisationszeitraum; durch den verspäteten Markteintritt geht zu Beginn Geld verloren; der Peak wird aber später wieder aufgeholt, sodass der Verlust begrenzt ist; Quelle: Joshua J. Arnold: „Urgency Profiles“ [5]

Abb. 7: Urgency Profile für ein Projekt mit langem Amortisationszeitraum; durch den verspäteten Markteintritt geht zu Beginn Geld verloren; der Peak wird aber später wieder aufgeholt, sodass der Verlust begrenzt ist; Quelle: Joshua J. Arnold: „Urgency Profiles“

Abb. 8: Urgency Profile für ein Projekt mit langem Amortisationszeitraum; durch den verspäteten Markteintritt geht zu Beginn Geld verloren; da der Peak später nicht wieder aufgeholt wird, entsteht ein praktisch unbegrenzter Verlust; Quelle: Joshua J. Arnold: „Urgency Profiles“ [5]

Abb. 8: Urgency Profile für ein Projekt mit langem Amortisationszeitraum; durch den verspäteten Markteintritt geht zu Beginn Geld verloren; da der Peak später nicht wieder aufgeholt wird, entsteht ein praktisch unbegrenzter Verlust; Quelle: Joshua J. Arnold: „Urgency Profiles“

Ein Sonderfall der CoD sind die Do Nothing Costs, die besonders bei technischen Backlog Items wie Architekturarbeiten interessant sind. Der Umgang mit diesen wurde in einem früheren Artikel beschrieben [3].

Bekannt geworden sind die CoD hierzulande vor allem durch Dean Leffingwells Adaption des Weighted Shortest Job First im Scaled Agile Framework. Diese Adaption entspricht exakt der oben beschriebenen Formel zur Priorisierung, wenn die CoD als Wert der Backlog Items eingesetzt werden.

Wertbasierte Priorisierung

Verwendet ein Product Owner den NPV oder die CoD zur Priorisierung des Backlogs, ist er ökonomisch auf der sicheren Seite. Natürlich kann man bei der Abschätzung der zukünftigen Cashflows für den NPV daneben liegen oder bei der Analyse der CoD falsche Annahmen zugrundelegen. Aber allein die analytische Beschäftigung mit dem Wert von Backlog Items führt in der Regel schon zu einer anderen Priorisierung einzelner Backlog Items. Das Bauchgefühl täuscht oft, was die Priorität angeht und die Analyse des Werts führt häufig zu überraschenden Ergebnissen.

Aber selbst wenn ein Product Owner keine konkreten Zahlen kennt oder in Geld messen kann, lässt sich mit diesen Modellen arbeiten. Der Autor hat bereits in einem Projekt Haselnüsse als Währung eingeführt und mit diesen die Cashflows für den NPV repräsentiert. Die Metapher ging auf: Im Backlog Grooming sprach man über den Wert der Backlog Items. Im Nachhinein repräsentierte jede Haselnuss mehrere tausend Euro, und sie schmeckten dem Team ganz hervorragend.

Die beschriebenen Modelle zur ökonomischen Betrachtung von Backlog Items ist für den Product Owner eine große Hilfe. Sie anzuwenden ist anstrengend und bisweilen kompliziert. Auf sie zu verzichten wäre aber grob fahrlässig, insbesondere im Zeitalter der Digitalisierung.

Geschrieben von
Gerrit Beine
Gerrit Beine
Gerrit Beine ist Managing Consultant bei der adesso AG mit den Schwerpunkten Agilität und Softwarearchitektur. Er ist regelmäßig als Sprecher auf Konferenzen zu treffen und beschäftigt sich gerne mit außergewöhnlichen Fragestellungen zur Softwareentwicklung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.