Eine der schwierigsten Aufgaben eines Product Owners ist die Priorisierung der Features seines Produktes. Hierbei kommt schnell der Geschäftswert (auch Businesswert, Business Value genannt) mit ins Spiel. Nicht jedes Unternehmen ist marktgetrieben und kann leicht feststellen, welchen Geldwert ein neues Feature haben wird. Der Wert eines Features wird dann oft auch nicht zuletzt durch den Zeitpunkt des Veröffentlichens mitbestimmt. Darum ist es besonders herausfordernd für den Product Owner die richtige Reihenfolge und den Zeitpunkt für die Veröffentlichung zu wählen. Häufig stehen die Stakeholder vor der Entscheidung, welches Feature einen höheren Wert hat und vor dem anderen ausgeliefert werden soll. Dabei wird dann immer wieder durch individuelle Vorlieben, subjektive Einschätzung und „Bauchgefühl“ eine Entscheidung durch den Product Owner getroffen. Die Meinungen der andern Stakeholder werden dabei nicht beachtet, was nicht selten zu Zwietracht zwischen allen Beteiligten führen kann.
Wann kann der Business Value hilfreich sein?
Ich den Einsatz des Business Values, also des Geschäftswertes, für sinnvoll und denke dieser wird oft unterschätzt. Zum einen erleichtert der Business Value dem Product Owner die Reihenfolge sinnvoll und mit begründeter Bewertung festzulegen. Oftmals beobachte ich, wie die Reihenfolge der PBIs durch eine Bauchentscheidung nach subjektivem Empfinden getroffen wird. Die Untermauerung der Entscheidung mit Hilfe eines Geschäftswertes ermöglicht eine etwas objektivere Herangehensweise an die Priorisierung von PBIs. Zum anderen hilft die Einschätzung des Business Wertes mir als Software Architekt immens beim Softwaredesign. Meist muss ich bei Architekturentwürfen beurteilen, wie viel Aufwand bei der Umsetzung eines neuen Features entsteht. Dabei ist oft ausschlaggebend wie viel dem Kunden diese neue Funktion wert ist.
[AMAZONPRODUCTS asin=“1942788045″]
Business Value hilft nicht nur dem Product Owner sondern auch mir als Software Architekt!
Als Architekt habe ich die Möglichkeit im Design der Software zu entscheiden, wie sie implementiert wird und mit welchem Aufwand. Eine Funktion mit einem gewingen Mehrwert aber hohen Implementierungskosten umzusetzen geht meißt am Ziel vorbei. Wenn ich als Architekt aber weiß, dass eine Funktion einen geringen Mehrwert hat, dann kann ich evtl. auch günstigere Alternativen finden, die ggf. nicht so komfortabel sind, aber für den Mehrwert, den sie bringen sinnvoll und geeignet sind. Leider habe ich hier immer wieder mit Product Ownern Diskussionen über den tatsächlichen Mehrwert von PBIs. Immer wieder gehen die Meinungen zur Sinnhaftigkeit von Anforderungen weit auseinander. Nicht selten haben wir aufwendig Anforderungen auf Wunsch des Product Owners umgesetzt, die später nachweislich nie genutzt wurden, oder dann sogar zurückgebaut werden müssen, weil sie im Arbeitsalltag ihren Zweck verfehlten. Und an dieser Stelle ist für mich der Business Value eine gute Möglichkeit eine zumindest „etwas“ objektivere Sichtweise auf die User Story zu bekommen.
Im klassischen Scrum ergibt sich der Business Value implizit aus der Reihenfolge bzw. der Priorität des Product Backlogs. Alle User Stories werden hier nacheinander aufgelistet, mit dem wichtigsten Backlog Item an oberster und dem unwichtigsten Item an letzter Stelle. Nicht zuletzt bei der festlegung genau dieser Reihenfolge kann der Geschäftswert sehr hilfreich sein.
Problematik mit dem Geschäftswert von User Stories
Oftmals wird der Business Value in Teams gezielt an User Stories eingesetzt, um die folgenden zwei Fragen zu beantworten:
- Wie viel „Geschäftswert“ liefert das Team dem Unternehmen pro Sprint?
- Wie soll ich User Stories priorisieren, und wie kann ich den Geschäftswert eine User Story gegenüber seinen Kosten stellen?
Den Businesswert so an User Stories zu knüpfen birgt einige Risiken. Zuallererst sind User Stories naturgemäß sehr kleinteilig. Diese Kleinteiligkeit macht es unter Umständen unmöglich einen wirklich aussagekräftigen Wert an die User Story zu binden. Darüberhinaus kann diese Kleinteiligkeit sehr komplex werden, um dann einer Funktionalität in der Summe seiner User Stories wirklich einen Geschäftswert zuzuordnen. Beispielsweis kann es schnell sehr komplex werden, wenn man z.B. den wirklichen Wert von Farbe, Schnelligkeit, PS, Verbrauch, Marke, etc. eines Autos ermitteln möchte. Außerdem kann der Geschäftswert einer User Sotry sehr gering sein, aber ohne diese User Story ist das Gesamtprodukt hinfällig. Ein Auto ohne Lenkrad wird schwer zu fahren sein.
Herausforderung beim Ermitteln der Kosten einer User Story
Nun, da wir die Schwierigkeit kennen, um den Geschäftswert von User Stories zu ermitteln können wir uns den zweiten Punkt anschauen, die Ermittlung der Kosten für eine User Story. Wenn wir versuchen über die konkrete User Story einen ROI zu ermitteln brauchen wir neben dem oben behandelten Geschäftswert auch die angefallenen Kosten. Bei User Stories und kleinen Features ist es häufig so, dass sie die Summe mehrerer User Stories sind. Eine User Story alleine umzusetzen erfordert meist einiges an Vorarbeit und ist aufwendig. Die folgenden User Stories dann anschließend umzusetzen wird leichter, da die Vorarbeit bei diesen dann nicht mehr anfällt. Des weiteren fällt meist der Aufwand für den Software-Architekturentwurf nur bei der ersten User Story an, nicht mehr aber bei den folgenden. Ein anschauliches Beispiel dafür sind User Stories für „Fleisch“ und „Leder“. Eine Kuh wurde aufgezogen mit dem Ziel ihr Fleisch und das Leder zu verkaufen. Können wir sagen, dass die Gesamtkosten der Aufzucht dem Fleisch zugeordnet wird und wir das Leder gratis dazu erhalten? Auch der Umkehrschluss wäre sicherlich eine falsche Rechnung. Die Gesamtsumme aus Leder und Fleisch muss in die Gesamtkalkulation der Aufzucht berücksichtigt werden. Gleiches gilt auch bei User Stories.
Was schlussfolgern wir nun daraus?
Bedeutet dies nun, dass der Businesswert für User Stories oder Features und damit der ROI nicht ermittelt werden können? Nein, das bedeutet es nicht, es zeigt nur auf, dass es sinnvoller ist den Business Value auf einer höheren Ebene und zwar von Epics (abstraktere, größere User Stories) und Gruppen von User Stories zu vergeben. Auf dieser Ebene kann dann ein viel aussagekräftigerer Geschäftswert ermittelt werden.
Wie nutzt Microsoft im TFS oder Visual Studio Online (VSO) den Business Value?
| Business Value* | A subjective unit of measure that captures the relative business value of a product backlog item or feature compared to other items of the same type. An item that is assigned a higher number should be considered as having more business value than an item that is assigned a lower number.
Added to these work item types (WITs):Epic, Feature |
Der Business Value ist laut MSDN im TFS am Epic oder am Feature lokalisiert. Wie zuvor bereits beschrieben ist eine Zuordnung auf Epic-Ebene empfehlenswert. Eine Prüfung im aktuellen Visual Studio Stand September 2016 zeigt, dass das Feld Business Value nun nur noch am Epic, nicht aber am Feature existiert.
Microsoft sieht dieses Feld als Zahlenwert vor, der beliebig eingetragen werden kann. Ein höherer Wert impliziert einen höheren Businesswert. Dies ist grundsätzlich schon einmal ein Anfang, endet aber meiner Erfahrung nach in absurden Zahlenreihen, damit man noch Anforderungen „dazwischen“ schieben kann, oder beliebig als „wichtiger“ und „weniger“ wichtig eingegliedert werden.
Welche Einheit für einen Business Value ist sinnvoll?
Welche Werte sinnvoll als Business Value einzutragen sind obliegt immer der Absprache zwischen Product Owner und Team. Eine beliebige Zahl, die je höher sie ist, einen umso höheren Business Value darstellt ist zumindest schon einmal ein Anfang. Wichtig ist, dass jeder unter den eingetragenen Zahlen das gleiche versteht. Besser wäre es sicherlich einen Businesswert in € einzutragen. Doch häufig ist es sehr aufwendig diese Zahlen auch messbar und fundiert zum Beispiel über das operative Controlling oder die Prozesskostenrechnung zu ermitteln.
[AMAZONPRODUCTS asin=“1604270314″]
Ich finde es einen guten Vorschlag den Business Value wie beim Planning Poker in einem Business Value Game zu schätzen. Mit dieser Methode kann auch der Product Owner mit seinen Key-Stakeholdern gemeinsam den Businesswert ermitteln und diese Schätzung dann für seine Priorisierung konsultieren. Dies ermöglicht den Stakeholdern für Epics und Features gemeinsam den Wert für das Unternehmen zu ermitteln, ohne dies der alleinigen Verantwortung des Product Owners zu überlassen. Nichts desto trotz muss respektiert werden, dass der Product Owner alleine die letzte Entscheidung über die Reihenfolge der Umsetzung von PBIs hat.
Den Geschäftswert durch den Zweck ermitteln
Eine schnelle und meiner Meinung nach einfache, aber effektive Art den Wert eines Features oder eines Epic zu bestimmen ist die Zuordnung von Zahlen abhängig vom Zweck des Feautures.
Hierzu nehmen wir die folgende Auflistung zur Hand:
1 – Bestandskunden oder Anwender glücklicher machen
2 – Bestandskunden oder Anwender begeistern
3 – Die Useability für Kunden oder Anwender dramatisch erhöhen
5 – Die Komplexität von Prozessen reduzieren und damit einen Zeitgewinn im Gesamtablauf
8 – Erfüllen eines Versprechens/eines Wunsches von Key-Usern/Anwendern, die sehr starken Einfluss auf das Gesamtprojekt haben
13 – Erfüllen von Strategischen- oder Geschäftszielen des Unternehmens
21 – Erfüllen von regulatorischen/Gesetzlichen Anforderungen (Es hat gerichtliche Konsequenzen, wenn diese nicht erfüllt werden.)
Die Zuordnung der Zwecke sollte je nach Produkt sinnvoll an die jeweilige Situation angepasst werden. Diese Liste ist ein Vorschlag, den ich im Projekt bereits erfolgreich angewandt habe. Vorteilhaft an dieser Liste ist, dass die Werte auch miteinander addiert werden können. Bspw. macht ein Feature bestandskunden glücklicher (1), reduziert dazu noch die Prozesskomplexität (5) und ist der Wunsch eines Key-Users (8), dann erhält das Feature den Wert 14.
*Externer Link, link öffnet ggf. in einem neuen Fenster
