Starten wir mit einem Beispiel, das sich immer wieder in agilen Projekten abspielt:
Ein Kollege (oder Stakeholder) kommt mit einem neuen Feature um die Ecke, das natürlich dringend noch in die Umsetzung muss. Auf die Frage des Product Owners, welchen Wert dieses Feature für den Kunden und somit auch für das Unternehmen hat, hat der Kollege keine passende Antwort parat.
Der Konflikt ist vorprogrammiert: Der Anforderer kann nicht für sein gewünschtes Feature argumentieren, der Product Owner kann das Feature nicht kategorisieren und somit nicht vor seinem Team oder der Geschäftsführung vertreten. Da beide den Wert nicht kennen, diskutieren sie hauptsächlich über den Aufwand und die Kosten des Features. Natürlich geht es auch ohne Business Value, allerdings wird dadurch die Frage "Entwickeln wir überhaupt das Richtige?" nicht objektiv genug bedient.
Warum ist die Wahl des Business Value wichtig?
Ein Business Value ist also eine Messgröße, die beschreibt, welchen Wert ein Produktmerkmal für ein Unternehmen hat. Man spricht auch vom Geschäftswert. Wichtig ist allerdings, dass man sich auf eine feste Messgröße einigt. Denn verschiedene Messgrößen lassen sich nicht miteinander vergleichen und machen eine Kategorisierung, wie wichtig ein Produktmerkmal ist, unmöglich.
Wie lässt sich ein Business Value bestimmen?
Die Bestimmung des Wertes kann auf Basis bereits vorhandener Messgrößen im Projekt geschehen. Das ist für jeden nachvollziehbar und relativ leicht umzusetzen. Eine weitere Möglichkeit zur Bestimmung des Business Value ist die demokratische Abstimmung. Man entscheidet im Projektteam gemeinsam, welcher Wert sich am besten eignet. Dadurch wird jeder im Projekt mit einbezogen und kann sich besser mit dem gewählten Wert identifizieren. Eine weitere Möglichkeit wäre, wenn der Vorstand oder Geschäftsführer den Business Value vorgibt. Man spricht dann von einer autokratischen Bestimmung.
Zur Wahl des richtigen Business Value kann das Agile Manifest helfen. Es besagt unter Prinzip 1 in seinen 12 agilen Prinzipien: "Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung von wertvoller Software / Produkte zufrieden zu stellen."
In vielen Projekten wird diesem Prinzip leider kaum Rechnung getragen. Die Fragen, denen oberste Priorität gegeben wird und die daher schon jeder mal gehört hat, lauten so:
- Sind wir noch auf Kurs?
- Sind wir noch im Kostenrahmen?
- Werden wir rechtzeitig fertig?
Für eine kundenzentrierte Ausrichtung entsprechend des Agilen Manifests fokussiert man sich auf diese Fragen:
- Welchen Wert schafft dieses Inkrement für den Kunden?
- Welchen Einfluss hat das auf das Geschäft des Kunden?
- Benutzen die Kunden das Produkt bereits?
- Entwickeln wir überhaupt das Richtige?
Eine interessante Methode, die als weitere Hilfestellung herangezogen werden kann, ist das Impact Mapping. Hierbei handelt es sich um ein Vorgehen, welches das Ziel hat, die an der Entwicklung beteiligten Mitarbeiter und deren Aktivitäten an einem gemeinsamen Geschäftsziel auszurichten.
Impact Mapping gibt eine Antwort auf die Frage "Warum macht wer, wie, was?" - also Warum wollen wir etwas tun? Wer sind die Akteure? Wie sind die Auswirkungen? Was ist das Ergebnis?
Fragen wie "Wie beurteilen wir den Einfluss auf unser Unternehmen?" oder "Wie können wir entscheiden, ob wir die richtigen Dinge entwickeln?" sollte man sich immer wieder auf Basis von Anforderungen, Features und User Stories im Team gemeinsam mit dem Product Owner stellen.
Wem es noch immer schwer fällt, in Business Value zu denken, versucht es mit einem anderen User Story Format. Eine übliche User Story verläuft nach dem Schema:
"Als (Rolle / Person) möchte ich (Feature), damit (Benefit / Wert) erreicht wird."
Formuliert man die User Stories entsprechend um in
"Wir werden (Benefit / Wert) schaffen für unsere (Rolle / Person), weil wir (Feature) entwickeln.",
hilft das, bei jeder User Story den Business Value in den Fokus zu stellen.
Bei der Wahl des Business Value sollte man auch die passende Währung nicht vergessen. Diese kann beispielsweise wie bei Story Points geschätzt werden, um zu bestimmen, welchen Wert ein Feature hat.
Kommen wir zurück auf unser Eingangsbeispiel. Die Entscheidung, ob der Product Owner das Feature noch mit in den laufenden Sprint nehmen soll, kann nun direkt anhand des Business Value erfolgen. Oder auch auf Basis des ROI, denn ROI = Business Value / Kosten. Anforderer und Product Owner stellen nun den vorab definierten Geschäftswert ins Zentrum ihrer Diskussion und nicht nur den Aufwand und die Kosten des Features.
