Business Value in agilen Projekten

Teile dies:

Eines der schwierigsten Dinge, die man herausfinden muss, wenn man Userstorys für ein Projekt priorisiert, ist: „Was ist der wahre Business Value dieser Story?

Der Product Owner hat die Aufgabe, das Backlog zu priorisieren. Doch wie soll er die Vielzahl der Storys am Anfang eines Projektes in die richtige Reihenfolge bringen? In sogenannten Grooming Meetings kann das Scrum Team die Userstorys durch-definieren und eventuell sogar schon mithilfe eines Planning Poker einschätzen. Dies hilft dem PO (Product Owner), komplexere Storys und damit Risiken zu erkennen. Um schneller zu lernen und Risiken zu vermeiden wird der PO komplexere Storys denen mit weniger Risiko vorziehen.

Dies beantwortet aber noch nicht die Frage, ob diese Userstory überhaupt einen Wert für das Unternehmen hat. So ein vorgehen reicht also nicht aus, um den größtmöglichen Wert (Business Value) mit den zur Verfügung stehenden Ressourcen zu erreichen.

Es fehlen Informationen. Nicht jedes Unternehmen hat strukturierte und marketinggetriebene Vertriebsprozesse, die im Detail bestimmen, was der genaue oder besser potenzielle Wert einer ausgelieferten Funktion/Userstory ist. Damit fallen genauere Aussagen, wie sie durch eine Break-even -, Cost of Delay -, Return Of Investment-, Casch-flow-Analyse oder durch den Net Present Value gemacht werden könnten, leider aus.

Häufig müssen die einzelnen Stakeholder daher aus dem Bauch heraus entscheiden, was wichtiger oder „wertvoller“ ist und als nächstes fertig gestellt werden soll. Dabei kommt es sehr häufig vor, dass sich diese Stakeholder nicht auf Prioritäten einigen können oder wollen, sondern ihre individuellen Wünsche an die Entwicklungsteams oder besser an den Product Owner (Scrum) weitergeben, der eigentlich für die Unterscheidung zwischen verschiedenen Stakeholderwünschen und -prioritäten zuständig ist.

Wie erreicht man nun einen gemeinsamen Konsens zwischen den verschiedenen Interessengruppen?

Wichtig dabei ist:

  • Die Prioritäten werden für das Unternehmen verstanden und definiert und nicht nur für einzelne Personen oder bestimmte Abteilungen.
  • Alle Stakeholder sind sich dessen bewusst und beteiligen sich an der Definition des für das Unternehmen wertvolleren Aspekts, ohne die gesamte Verantwortung an Product Owner zu delegieren.

Dabei darf nicht außer acht gelassen werden, dass der Product Owner die „ultimative“ Rolle ist, die für die Definition der Produktprioritäten verantwortlich ist und das Produkt owned, selbst wenn er wie in diesem Fall von Experten unterstützt werden muss.

Denn die Priorisierung kann weitere Abhängigkeiten beinhalten. Auch wenn Userstorys unabhängig voneinander sein müssen und einen Wert für sich darstellen, so sind doch häufig bestimmte Reihenfolgen oder das aufeinander Aufbauen wichtige Aspekte für die Priorisierung. Daneben kann es auch viele weitere Aspekte geben. Zum Beispiel neben dem Risiko der reinen Komplexität, auch das des nicht wissen/kennen. Wenn z.B. Prototypen gebaut werden oder neue Technologien eingeführt werden müssen, ist auch dieses Risiko mit in der Planung zu berücksichtigen.

Steakholder müssen verstehen, dass der PO dieses Wissen durch den regen Austausch mit den Steakholdern und dem Team als einziger in ausreichender Tiefe erlangen kann, um die Prioritäten zu bestimmen.

Daher muss dem Product Owner von allen Seiten das „Highlander-Prinzip“ (es kann nur einen geben) zugestanden werden. Oft sind sich die Beteiligten über diese exponierte Rolle des PO nicht im Klaren. Daran scheitern viele Projekte!

Wie so viele andere Aspekte des agilen Vorgehens ist auch dieser Vorgang natürlich mit Arbeit verbunden. Diese Arbeit nicht zu machen ist allerdings keine Lösung, um mehr Wert für ein Unternehmen zu schaffen.

Allgemein gilt, dass diese Abstimmung im sogenannten „Product Management Board“ Meeting abgehalten wird. Das Meeting hat eine vorher festgelegte Time-Box in Abhängigkeit des Umfangs. Sinnvoll ist hier z.B. der Einsatz einer Eieruhr, um die Zeit, in der über eine Story diskutiert wird, einzugrenzen und so nicht aus der Gesamt-Time-Box zu laufen.

In diesem Meeting werden die Relationen zwischen den einzelnen Zielen (Mehrwerten) festgelegt, natürlich vorausgesetzt, es gibt mehr als ein Ziel.

Die Ziele werden normalerweise in vier Hauptkategorien unterteilt:

  • New Business: Jede Funktion, die potenzielle neue Kunden oder Märkte erschließt, bringt auch einen zusätzlichen Geldfluss mit sich.
  • Up Selling: Jede Funktion, die potentiell mehr Geld von bestehenden Kunden bringt und als Add-on, Upgrade oder Plug-In verkauft werden kann.
  • Retainment: Jedes Feature, das den Verlust von Kunden und gleichzeitig den Verlust von Geld für das Unternehmen vermeidet.
  • Effizienz: Jedes Feature, das es dem Unternehmen ermöglicht, Geld (Kosten) zu sparen, da es eine potenzielle Verbesserung gibt.

Im Verlauf des Meetings gibt es dann verschiedenste Methoden, den Mehrwert für eines dieser Ziele zu bestimmen. In Abhängigkeit des zuvor erzielten Konsens über den relativen Wert dieser Ziele zueinander ergibt sich dann eine Priorisierung nach Business Value (größtmöglich zu schaffender Mehrwert für das Unternehmen mit den zur Verfügung stehenden Mitteln in minimaler Zeit).

 Mehr dazu in meinem Buch:

Agiles Projektmanagement: Kreiere maximalen Business Value: Starte mit kundenzentrierter Sichtweise und maximierter Wertschöpfung in eine gesicherte Zukunft (Digitalisierung 2)

 

Bild-Quelle: Scrrenshoot excalibur.com