Share ZU:
12 September 2017 @ Philip Stolz

Cash, Stakeholder, Value – die drei Dimensionen des Business Values

Business Value hat 3 Dimentionen: Cash, Stakeholder und Value
Business Value – 3 Dimensionen

Zur Einschätzung des Business Values einzelner Produktfeatures oder User Stories hilft die Erkenntnis, dass Business Value immer durch Zusammenwirken der Dimensionen Cash, Stakeholder und Value entsteht.

Die Bewertung des Business Values ist nicht einfach

Bei der Releaseplanung gilt das Prinzip, den Business Value des Produktes zu optimieren.

Was hier sehr einfach in einem Satz beschrieben ist, stellt Product Owner und Produktmanager regelmäßig vor Herausforderungen. Man sagt zwar, ein guter Product Owner könne den Business Value mit seinem Bauchgefühl bewerten, jedoch sieht sich jeder noch so gute Product Owner hin und wieder mit der Situation konfrontiert, dass er zu bestimmten Dingen kein Bauchgefühl hat.

Wikipedia beschreibt den Begriff Business Value folgendermaßen:

In management, business value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run. …

Wikipedia (Stand 2017-09-01)

Das Konzept Business Value ist also vielschichtig. Es lässt sich nicht einfach auf eine einzelne Messgröße reduzieren. Das macht aber auch nichts. Denn es geht nur darum, Features aufgrund ihres Business Values in eine sinnvolle Reihenfolge zu bringen.

Ein Bauchgefühl entwickeln

Um ein Bauchgefühl für den Business Value eines Features zu entwickeln, kann man versuchen, für das jeweilige Feature eine Hypothese zu entwickeln, wie das Feature Business Value erzeugen könnte. Das gelingt durch Projektion des Features auf die drei Dimensionen Cash, Stakeholder und Value. Dabei versuchen wir uns ein Bild durch Anwendung des nachfolgend beschriebenen Fragemusters zu machen.

Fragemuster Dimension
Wer bezahlt dem Unternehmen Geld oder welches Geld spart das Unternehmen mittelbar oder unmittelbar, Cash
da welcher Stakeholder Stakeholder
welchen Wert/Nutzen hat? Value

 

Die so gewonnene Hypothese muss nach erfolgreicher Umsetzung des Features validiert werden, da wir sonst nicht wissen, wie gut unser Bauchgefühl ist und wir so die Entwicklung des Bauchgefühls nicht gezielt verbessern können.

Beispiel: Online-Mitfahrzentrale

Sehen wir uns folgende User Story-Beispiele aus dem Kontext einer Online-Mitfahrzentrale an:

ID Kurzbezeichnung User Story Text
US-437 Nutzerverhalten Als Web-Designer möchte ich Statistiken zum Nutzerverhalten abfragen, um die Performance verbessern zu können.
US-329 Communitygröße Als Marketingabteilung möchte ich die tagesaktuelle Anzahl der registrierten Benutzer auf der Homepage präsentieren, um die Größe der Community zu zeigen.
US-416 Hundebox Als Hundebesitzer möchte ich im Profil des Fahrers sehen können, ob das Fahrzeug über eine Hundebox verfügt, um meinen Hund sicher transportieren zu können.

 

Bevor wir weitermachen, lassen sie nun bitte ihr Bauchgefühl entscheiden, welche der drei User Stories aus ihrer Sicht den größten – und welche den geringsten Business Value darstellt.

Den Business Value mit Hilfe des Fragemusters bewerten

Durch Beleuchten hinsichtlich der drei genannten Dimensionen, konnten wir die folgenden Hypothesen über den Business Value jeder einzelnen User Story entwickeln:

USR-437
Nutzerverhalten
USR-329
Communitygröße
USR-416
Hundebox
Dimension
Werbekunden bezahlen Geld, Das Marketing spart Geld und Werbekunden bezahlen Geld, Werbekunden mit gezielter Werbung für Hundebesitzer bezahlen Geld, Cash
da der Webdesigner da für potentielle Nutzer und für Werbekunden da manche Hundebesitzer Stakeholder
die Performance derart verbessern kann, dass viele Nutzer von Konkurrenzportalen zur Online-Mitfahrzentrale wechseln. die hohe Anzahl an Mitgliedern sehr attraktiv ist. die Plattform nur dann nutzen, wenn sie die Verfügbarkeit einer Hundebox prüfen können, ohne Kontakt zum Fahrer aufnehmen zu müssen. Value

 

Entscheiden sie nun noch einmal, welche der gelisteten User Stories aus Ihrer Sicht den größten – und welche den geringsten Business Value darstellt.

Falls sie nun zum selben Schluss wie bei ihrem ersten Versuch kommen, dann hatten sie ein sehr gutes Bauchgefühl. Falls ihr Urteil beim zweiten Mal anders ausfällt, dann haben sie für sich den Beweis, dass ihnen das vorgestellte Fragemuster dabei hilft, ein Bauchgefühl zu entwickeln.

Entstehung dieses Ansatzes

Im Rahmen des CARS-Kurses wurde Product Ownern immer wieder die Aufgabe gegeben, Stichworte für ihr Verständnis des Begriffs Business Value in ihrer täglichen Arbeit zu sammeln. Das ursprüngliche Ziel war es, den Product Ownern die Vielschichtigkeit des Begriffes zu verdeutlichen. Bei den Ergebnissen dieser Übung fiel auf, dass sich alle gesammelten Stichworte den genannten Dimensionen Cash, Stakeholder und Value zuordnen ließen. Die Erkenntnis, dass sich der Begriff Business Value damit im Rahmen dieser Dimensionen bewegt, sollte es uns einfacher machen, den Business Value von Produktfeatures oder User Stories einzuschätzen.

Schauen Sie sich auch unsere Trainings zum Requirements Engineering an. Es gibt den Intensivworkshop zur IREB® CPRE-Foundation Level ZertifizierungCPRE Advanced Level, oder das bereits genannte Training zum Certified Agile Requirements Specialist (CARS). 

Verwandte Themen und Links

  1. Impact Mapping: Ein ebenfalls sehr guter Ansatz zur Bewertung, wie sich eine User Story oder ein Feature auswirkt.
  2. The Business Model Canvas: Eine Vorlage, die dabei hilft, ein Business Model zu verstehen und damit auch den Business Value von Produktfeatures besser einzuschätzen.
  3. Product Vision Board: Eine Vorlage zur Entwicklung einer Produktvision – Diese nutzt ähnliche Begriffe, um Produktfeatures in einen Kontext zu setzen.
  4. Certified Agile Requirements Specialist (CARS): Zweitägiges Intensivtraining, bei dem unter anderem das Entwickeln einer Produktvision und die Releaseplanung geübt wird.
  5. Product Backlog initial befüllen: Eintägiges Training, bei dem unter anderem das Priorisieren nach Business Value behandelt wird.
  6. RE@Agile Primer: Eintägiges Training, durch das man einen guten Überblick über agile Produktentwicklung erhält.

Philip Stolz

Kontaktieren Sie Philip Stolz

Herr Philip Stolz ist als Senior Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung und Prozessverbesserung von Requirements Engineering (RE). Herr Stolz verfügt über eine fundierte Ausbildung im Bereich Software Engineering (Dipl.-Inf., Softwaretechnik). Durch Erfahrung aus unterschiedlichen Entwicklungsprojekten in verschiedenen industriellen Branchen sind ihm typische Projektsituationen sowie das Vorgehen bei der Einführung methodischer Verfahren innerhalb von Projektteams bekannt.

← Früher
Nächste →