Die Sache mit dem Business Value

Es passiert schon wieder: Da steht ein Stakeholder vor dem Product Owner und fordert, dass etwas ganz wichtiges in den Sprint muss. Und jetzt?

Jetzt kann man sich als PO entscheiden, ob man der „Story-Schubser“ und Prügelknabe wird, weil man nur noch das Chaos verwaltet und versucht, die verschiedenen Stakeholder nach Gutdünken unter einen Hut zu bekommen – Hint: klappt nicht, daher wird man automatisch zum Prügelknaben. Oder ob man versucht, sein Produkt wirklich zu „ownen“.

Gerade in Zeiten von Kurzarbeit ist der Tag eines Teams noch wertvoller und knapper. Er muß also gut investiert sein.

TL;DR 

Den Business Value zu ermitteln ist nicht immer leicht. Was wäre, wenn man es von der Kostenseite betrachtet? Auch eine ungenaue Zahl ist hier besser als keine.

Frag doch mal nach dem Business Value

Gehen wir doch mal gemeinsam den Weg des Product Owners. Zurück zum Anfang. Es treten auf: Frank (Stakeholder) und Paul (Product Owner).

Frank: „Paul, ich brauche da dieses Feature im nächsten Sprint.“

Paul verzieht leicht das Gesicht, weil er den Mehrwert für die Company nicht sieht und es im Backlog echt wichtigeres gibt. Aber er fragt höflich.

Paul: „Gern, wenn es mehr Wert für die Company hat als die obersten Dinge im Backlog. Welchen Business Value hat dein Feature denn?“

Frank: „???“

Paul: „Was bringt es uns, wenn wir das machen?“

Frank: „Das ist wichtig, sonst können wir das nicht an diese Gruppe von Kunden verkaufen.“

Paul: „Verstehe ich. Ich brauche aber ein Business Value, damit ich es einordnen kann.“

Frank verläßt die Bühne. Es tritt auf: Walter, Geschäftsführer.

Walter: „Paul, Frank war gerade bei mir und hat mir erzählt, dass du sein Feature nicht umsetzen willst. Das ist total wichtig und es kommt in den nächsten Sprint. Ende der Durchsage.“

Paul: „Ja, Chef …“

Hier ergibt es dann auch keinen Sinn mehr, darüber zu diskutieren. Weder Frank noch Paul haben Zahlen, mit denen sie argumentieren könnten. Und viel schlimmer noch: Paul ist zum Story-Schubser geworden und wird von den anderen Stakeholdern die Prügel einstecken, weil sie ihre zugesagten Features nicht bekommen haben.

Kenne die Kosten deines Sprints

Wie kann Paul in seiner Rolle als Product Owner das Problem lösen? Der effektivste PO ist ein PO, der eine Art Mini-CEO im Unternehmen ist.

Wie ein CEO das Unternehmen lenkt, lenkt ein PO sein Team. Wie ein CEO macht ein PO ständig Kosten-Nutzen-Abwägungen. Sollte er oder sie zumindest. Tun aber die wenigsten, obwohl es nicht sonderlich schwer ist.

Die Kostenseite der Betrachtung ist dabei tatsächlich die Einfachste. Was braucht Paul, um die Kosten für ein Feature zu ermitteln? Erstmal die Kosten für einen Sprint. Nichts einfacher als das.

Bei einer Sprintlänge von zwei Wochen und durchschnittlich 21,5 Arbeitstagen pro Monat – also zwei Sprints pro Monat – wären das rund:

\(\frac{Summe \, der \, Monatsgehälter \, des \, Teams \, * \, 1,2 \, (für\, die\, Lohnnebenkosten)}{2}\)

Ja, es ist nicht ganz genau, aber jede genäherte Zahl ist besser als keine Zahl. Daher ist es im ersten Schritt, falls man nicht an die Gehaltssumme herankommt, auch völlig in Ordnung, einen marktüblichen Durchschnittswert zu nehmen. Verfeinern kann man immer. Doch dazu später mehr.

Bei einem Team aus fünf Entwicklern, einem Product Owner und einem Scrum Master kommt folgende Summe zusammen (Durchschnittsgehälter Bayern):

\(\frac{(5 \, * \, 4.166 \, € \, + \, 5.000 \, € \, + \, 4.583 \,€ ) \, * \, 1,2}{2}\ \, \approx \, 18.248 \, €\)

Was kostet eine Story?

Die reinen Kosten für einen Sprint nützen noch recht wenig. Wie kommen wir jetzt auf die Kosten einer Story?

Das macht tatsächlich Arbeit, falls man keine Zeiterfassung in dem Tool seiner Wahl hat. Hätte man ein Zeiterfassung, könnte man sich einfach einen Report rauslassen und sähe die investierte Zeit pro Story/Feature.

Falls das nicht existiert, muss das ganze Team mithelfen. In einem Meeting wird die aufgewendete Zeit der bereits in der Vergangenheit erledigten Stories „post mortem“ geschätzt. Hier gibt es verschiedene Herangehensweisen: „Irene und Simon haben dafür gemeinsam fünf Personentage gebraucht“. Oder „Die Story hat 20 Prozent von unserem Sprint gekostet“.

Letztlich kommt direkt oder rechnerisch eine Zahl an Personentagen pro Story heraus. Sammelt man diese und stellt sie in einem Histogramm dar, kann man vielleicht verschiedene Häufungen erkennen. Besser sind natürlich historische Daten (s. unten, „Genauere Zahlen, bitte!“).

Aus den Häufungen im Histogramm leiten wir ein paar Klassen ab, geben ihnen T-Shirt-Größen (nur ein Vorschlag) und schreiben noch die durchschnittlich (besser: den Median pro Klasse/Intervall) benötigten Personentage auf. Und jetzt?

In unserem Beispiel hat ein Sprint 50 Personentage (fünf Entwickler, 10 Tage, Product Owner und Scrum Master sind auf die Tage umgelegt). Ein Personentag im Sprint kostet also € 18.248 / 50pt = € 365,- / pt (aufgerundet).

Perfekt! Jetzt haben unsere T-Shirt-Größen also auch Preise.

Umgekehrt: Sag doch mal was es kostet

Was bringt die ganze Übung jetzt? Unser Product Owner Paul kann jetzt eine ganz andere Diskussion führen. Wenn ein Stakeholder ihm kein Business Value nennen kann, kann er eines Errechnen. Eine Unterhaltung könnte so aussehen.

Es treten auf: Frank (Stakeholder) und Paul (Product Owner).

Frank: „Paul, ich brauche da dieses Feature im nächsten Sprint.“

Paul: „Gern, welchen Business Value hat dein Feature denn?“

Frank: „Keine Ahnung, ist aber echt wichtig!“

Paul ruft das Team zusammen.

Paul: „Sagt mal, welche T-Shirt-Größe hat Franks Feature?“

Team: „Boah, das ist fast so wie diese Features, die wir schon mal entwickelt haben. Die waren alle M. Ein paar waren auch L.“

Paul: „Frank, wenn wir das jetzt für dich entwickeln sollen, sagst du implizit, dass dein Feature uns mindestens € 7.665,- einspielt. So viel kostet es uns in der Entwicklung.“

Frank: „Öh …“

Ab diesem Zeitpunkt kann eine zahlenbasierte Diskussion zwischen Product Owner und Stakeholder, sowie zwischen den Stakeholdern untereinander stattfinden.

Wenn wir € 7.665,- investieren und dafür den Gegenwert erhalten, ist das gut. Falls nicht, sollten wir es nicht machen. Wenn wir alle geplanten Dinge nach hinten schieben, damit dieses eine Feature jetzt (!!) gemacht werden kann, muss uns das über die nächste Sprintlänge mehr einbringen, als die Stories, die wir dafür nach hinten schieben würden, in der selben Zeit einbrächten.

Hier kommt eine Betrachtung des Cost of Delay zum Tragen. Doch das ist Thema für einen eigenen Post.

Genauere Zahlen bitte!

Mit der ersten groben Zahl, basierend auf öffentlichen Durchschnittsgehältern, hat unser Product Owner die Diskussion angestoßen. Wie bekommt man genauere Zahlen?

• Reale Gehaltssummen zugrunde legen
• Tagessätze von Dienstleistern einbeziehen
• Arbeitsplatzkosten umlegen (die Buchhaltung hilft da bestimmt weiter)
  • Anteilige Miete
  • Rechner (Leasing oder Abschreibung)
  • Lizenzkosten für genutzte Tools
• Real investierte Personentage pro Story erfassen (manuell oder im Tool)

Bitte, bitte … keine Erbsen zählen! Es darf gerundet werden und die kleinste Einheit ist ein Tag oder ein Euro.

Kosten pro Story Point?

Können wir nicht einfach die Kosten pro Story Point berechnen? Immerhin haben wir ja die Kosten pro Sprint und die durchschnittlichen Story Points pro Sprint, a. k. a. Velocity? 

Ja, könnten wir. Sollten wir das tun? Nein, bloß nicht!

Story Points sind eine Schätzung der Komplexität. In Komplexität steckt keine Betrachtung der Zeit. Komplexität kann man nicht in Geld umrechnen. Es kann sein, dass ein Team eine komplexe Story mit viel Unsicherheit innerhalb eines Sprints umsetzt, eine triviale Aufgabe braucht aber mehrere Sprints, weil es eine lange Liste abzuarbeiten gilt.

In der Praxis habe ich auch schon gesehen, dass eine solche Zahl zu komischen Situationen bei den Schätzungen führt. „Warum ist das denn eine 8? Ich habe nur Budget für eine 3. Das ist doch höchstens eine 3!“

Sobald solche Diskussionen aufkommen – und das werden sie, sobald man Kosten pro Story Point berechnet – bricht das System der Schätzungen zusammen. Man kann es sich also gleich sparen und wieder in den planerischen Blindflug übergehen.

Lasst eure Story Points in Ruhe und frei von einer Zeitkomponente!