Diskussion des „Rapid Business Value Calculation Tool“ von Scrum Inc.

Teile diesen Beitrag mit deinen Freunden!

Ist die Arbeit des Scrum Team wert-voll? Wie kann sichergestellt werden, dass an den richtigen Themen gearbeitet wird? Heute geht es über die Ermittlung des finanziellen Wertes von Backlog Items mit Hilfe des 2014 vorgestellten „Rapid Business Value Calculation Tool“ von Scrum Inc.

Pro Person betragen die Personalkosten im Jahr ca. 100.000 Euro[1], ein 10-köpfiges Team (mit Product Owner und Scrum Master) kostet also das Unternehmen ca. 1 Mio. Euro pro Jahr. Ein zwei Wochensprint kostet ca. 42.000€. Die Gesamtkosten pro Stunde und Kopf sind ca. 60€. Daher ist es wichtig zu wissen, ob die getätigten Investitionen den gewünschten Mehrwert erzeugen.

Der Product Owner ist gefordert, die Reihenfolge der Themen im Backlog entsprechend vorzugeben. Er soll so priorisieren, dass die Items mit dem höchsten Wert als erstes angegangen werden. Das Backlog besteht aber nicht nur auf Features, Epics und User Storys. Verschiedene andere Items konkurrieren im Backlog gegeneinander um die DevTeam Ressourcen: Explorationen, Bugfixes, Verbesserungsmaßnahmen aus der Retrospektive, sonstige Aufgaben. Der P.O. benötigt also eine Möglichkeit, für all diese Themen den Wert bestimmen zu können und die Kosten[2] zu berücksichtigen.
In den INVEST-Kriterien, die häufig Bestandteil einer Definition of Ready sind, steht „V“ für Valuable. Es liegt an dem Product Owner, die wertvollsten Items zu bestimmen. Dazu muss er Kosten und Nutzen gegenüberstellen.

Im Refinement Meeting werden die Epics und deren Storys mit Story Points geschätzt. Der P.O. bekommt so eine Aussage zum Risiko[3] der Umsetzung.
Er hat aber noch keine Einschätzung zu den monetären Kosten des Epics. Zusätzlich benötigt der P.O. eine Aussage zum Wert dieses Epics[4], welches ebenfalls in die Priorisierung einwirkt. Dabei sollten die Methoden zur Wertermittlung so gestaltet sein, dass sie schnell ausführbar sind, um die Wertabschätzung stets aktuell halten zu können.

Scrum Inc., das Unternehmen von Jeff Sutherland, hat 2014 Tabellenkalkulationsblatt entwickelt[5], welches die Berechnung der von Entwicklungsthemen wie Epics und Features, aber auch die Berechnung von immateriellen Backlog-Themen ermöglichen soll. Das Tool soll „die Diskussion zwischen Product Owner und Team über den Geschäftswert von Epics im Backlog fördern“. Als Ergebnis liefert die Kalkulation den Kapitalwert (Net Present Value, NPV) pro Story Point.

Die Autoren erwarten bei der Anwendung dieser Methode

  • Sensibilisierung des ScrumTeams für das Verhältnis von Wert und Aufwand
  • Priorisierungsprobleme innerhalb des Unternehmens (z.B. persönliche Vorlieben, machtpolitische Entscheidungen) werden behoben
  • Annahmen, die im MVP[6] validiert werden sollten, können herausgearbeitet werden

Die Berechnung[7] besteht aus drei Bestandteilen:

 

Ablauf:

  1. Berechnen des Kapitalwertes des Product Backlog Items (PBI)
  2. Hinzuaddieren des Wertes von immateriellen Nutzen
  3. Abschätzen der Story Points zur Umsetzung des PBI
  4. Berechnen des NPV pro Story Point

Wenn der Product Owner für alle PBI diese Berechnung durchgeführt hat, kann er die Priorisierung durchführen.


Details

Das Kalkulations-Tool besteht aus vier Tabellenblättern „Input“, „Output“, „Calculations“, „Variables“ und eine Seite mit Anleitungen.

Input Tab

Alle Eingaben erfolgen im „Input“ Tab. Der Name des PBI (bzw. des Epics), das heutige Datum, der kalkulatorische Zinssatz und der betrachtete Zeitraum werden hier außerdem erfasst.

Beschreibung des Cash Flows (Cash Flow Description)
  • Zu berücksichtigende Cash Flows
  • Einnahmen oder Ausgaben
  • Finanzielle Höhe
  • Zeitpunkte der Ein- oder Auszahlung
  • Zeitraum des Cashflows
  • Wachstumsrate
Immaterieller Nutzen (Other Intangible Benefit)

Falls es schwer ist, den finanziellen Wert eines PBI abzuschätzen (z. B. bei Explorationen oder Maßnahmen aus der Retrospektive zur Verbesserung der Zusammenarbeit), wird mit einer Referenzstory gearbeitet, die einen bekannten finanziellen Wert hat[9]. Diese Wert-Referenzstory wird mit 3 Story Points verankert. Das Team schätzt nun mit Planning Poker den Wert des Backlog-Items in Bezug zu dieser Wert-Referenzstory.
Angenommen, die Wert-Referenzstory hat einen Wert von 5.000 € bei 3 Story Points. Beim Planning Poker zum Wert des abzuschätzenden PBI einigt man sich auf 8 SP. Das Tabellenblatt rechnet nun

Mit den ermittelten Werten ergibt sich ein immaterieller Nutzen des PBI von ca. 13.000 €.

Erstmalige Aufwandschätzung (Initial Estimate of Effort)

Die User Storys zur Umsetzung des Epics werden aufgelistet und mit der jeweiligen Story Point-Schätzung eingetragen. Für die weitere Berechnung werden alle Story Points des Epics zusammengezählt.

Output Tab

Hier wird der errechnete Kapitalwert des PBI gesamt und pro Story Point präsentiert, jeweils ohne oder mit immaterielle Nutzen.

Der Product Owner würde nun die Product Backlog Items so priorisieren, dass zuerst jene gemacht werden, die den höchsten NPV/Point haben.

 

Als zusätzliche Information wird auch die zeitliche Verteilung und Höhe des Cash Flows wird grafisch nach Zeitpunkten und kumuliert dargestellt.

 

Kritik

Manchmal kann man in der Welt der agilen Software-Entwicklung die Aussage lesen: „Das Team konnte im letzten Sprint 20 Story Points an Wert liefern“. Diese Bedeutungsgleichheit von Story Points und geliefertem Wert will sich mir aber nicht erschließen. Ob die Arbeit am Sprint Backlog wirklich einen, zu den Story Points äquivalenten, Geschäftswert liefern kann, ist nicht garantiert. Die Begrifflichkeiten der Benutzungsanleitung des Calculation Tools sind mir in diesem Punkt dann auch nicht genau genug. Begriffe wie „Value“, „Effort“ und „Story Points“ gehen zu sehr durcheinander[10]. Es sollte klarer herausgestellt werden, dass

  • Story Points verwendet werden, um (nach meiner Definition) das Risiko der Umsetzung des Product Backlog Items zu beschreiben
  • Value Points (o.ä.) verwendet werden, um den Wert des Product Backlog Items für das Unternehmen zu beschreiben

Die Verwendung des englischen Begriffes „Effort“ bietet bei der Übersetzung ins Deutsche eine Reihe von semantischen Verwechslungsmöglichkeiten: Arbeitsaufwand, Leistung, Kapazität u.a.
Der Product Owner sollte sich dieser Bedeutungsvielfalt bewusst sein und die geeigneten Worte verwenden.

Der Product Owner sollte aber auch die generellen kritischen Stimmen zum Versuch einer Backlog Priorisierung mit finanzmathematischen Verfahren kennen:
Luke Hohmann[11] führte 2008 eine Reihe von Argumenten auf, warum für ihn eine Priorisierung basierend auf ROI (und anderen Bewertungsinstrumenten der Investitionsrechnung wie NPV, Amortisation) problematisch ist: Um eine belastbare Aussage zu bekommen, sei eine angemessene Marktforschung notwendig. Die Zeit, welche dafür benötigt werde, sie oftmals länger als der Release-Zyklus des Entwicklungsteams. Ebenso führten die entstehenden Kosten (mehrere 100T$) dazu, dass ein Unternehmen kaum mehr als 1 Marktforschungsprojekt pro Jahr finanzieren würde. Hohmann vermutet, dass Experten trotzdem weiterhin eine Priorisierung auf Basis von Geschäftswert anpreisen würden, da sie es leichter mache, eine agile Vorgehensweise an „MBA-trained Senior Executives“ (also Entscheidungsträger mit einer MBA-Ausbildung) zu verkaufen.
Daniel Zacarias[12] beschreibt verschiedene finanzmathematische Methoden (u.a. NPV), die zu Priorisierung herangezogen werden können. Er warnt jedoch davor, eine quantitative Methode isoliert von einer anderen quantitativen Methode zu betrachten bzw. isoliert von andern Priorisierungsmethoden. Manchmal sei es aber eine Vorgabe des Unternehmens, eine finanzielle Analyse eines Entwicklungsvorhabens durchzuführen.

Anmerkungen

Value Points sollten ebenso schnell abgeschätzt werden können, wie Story Points. Die Berechnung des NPV/Point kann der Product Owner losgelöst im Vorfeld zu den Refinement Meetings tun. Er kann verschiedene Tabellenblätter bereithalten, die einen vorbereiteten Berechnungsrahmen mit Parametern für typische Backlog-Items beinhalten.

Schwierigkeiten könnten auftreten, wenn die Referenzstory für den immateriellen Nutzen gefunden werden soll. Es sollte eine Aktivität sein, die das DevTeam gemeinsam durchgeführt hat und die einen Wert besitzt. Ggfs. eignet sich hier z.B. ein durchgeführter Bugfix, der dem Unternehmen bekannte Kosten eingespart hat.

Elena Yatzeck[13] weist darauf hin, dass Value Points sich ebenso wie Story Points im Laufe des Projektes verändern können, da der Markt und die User sich ändern. Es wird also notwendig sein, immer wieder auf den geschätzten Wert zu schauen und die Annahmen überprüfen. Ein Über-Analysieren sollte daher vermieden werden.

 Schlussbemerkung

Im Gegensatz zu den vielen anderen Priorisierungsmethoden gefällt mir bei der NPVperPoint Methode besonders, dass der Versuch unternommen wird, den finanziellen Wert aller Aktivitäten zu ermitteln. Vor allem auch jener, die keine User Story sind, aber trotzdem einen Wert besitzen. Beim Abschätzen der Dringlichkeit von Maßnahmen aus der Retrospektive oder bei der Bug-Triage können neue Erkenntnisse gewonnen werden, wenn versucht wird, den finanziellen Wert des Themas greifbar zu machen.

Wenn man als P.O. in einem Unternehmen die Situation hat, dass Stakeholder bestimmte Lieblings-Features „durchdrücken“ wollen und der Konflikt auf dem Rücken des ScrumTeams ausgetragen wird, dann kann eine finanzielle Analyse nach althergebrachter und bekannter Weise die Stakeholder dazu zwingen, von persönlichen Vorlieben Abstand zu nehmen und einer Priorisierung zum Wohl des Unternehmens zuzustimmen.

Wie bei allen anderen Aktivitäten sollte der P.O. genau überlegen, wofür die zur Verfügung stehende Arbeitszeit aller im ScrumTeam beteiligten Personen eingesetzt wird. Dies gilt auch für den Aufwand, der bei der Priorisierung betrieben wird. Bei manchen Backlog-Items ist es z.B. sofort klar, welcher Rang im Backlog der Richtige ist, ohne dass überhaupt explizit eine Priorisierungsmethode angewandt wird. Diese Zeit kann man sich sparen. Andere Backlog-Items müssen mit einem Methoden-Mix betrachtet werden, um verschiedene Aspekte zu beleuchten.


[1] Lt. Gehaltsrechner von Alpha Personalservice GmbH, bei ca. 68.000€ Jahresbrutto, https://www.personalservice-alpha.de/pkr#

[2] Ggfs. auch die laufenden Kosten, die während des Betriebes entstehen, z.B. Bugfixing, Konfiguration, Kundensupport

[3] Siehe meinen Blog-Eintrag https://cmmann.de/story-points-in-den-richtigen-haenden-ein-machtvolles-konzept/

[4] Mike Cohn schlägt vor, eine Gesamtbetrachtung des Wertes eher auf Basis von Epics, also mehreren zusammenhängenden User Storys durchzuführen, als auf einzelnen User Storys. https://www.mountaingoatsoftware.com/presentations/prioritizing-your-product-backlog

[5] Brown, Alex, und Sutherland, Jeff. „www.scruminc.com.“, https://www.scruminc.com/calculating-business-value/
Auch ein Webinar ist unter oben genannter Quelle verfügbar.

[6] MVP Minimal Viable Product: Frühe Produktversion zur Validierung von Annahmen über Geschäftsmodell, User und Markt

[7] Das Excel-Sheet von Scrum Inc. zur Berechnung des NPV/Point kann heruntergeladen werden unter https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiekI2YgPfTAhVLliwKHUINDgcQFggnMAA&url=https%3A%2F%2F34slpa7u66f159hfp1fhl9aur1-wpengine.netdna-ssl.com%2Fwp-content%2Fuploads%2F2014%2F07%2FQuick_NPVperPoint_Template.xlsx&usg=AFQjCNF5TEtG2b3OKfECoxU9-iidLDw7qA&sig2=P_iSgoEsFieK2W_0aIRrlA&cad=rja

oder Websuche nach „npv per point template“

[9] Im Webinar von Scrum Inc. wird die Durchführung einer Scrum Master Schulung als Referenzstory verwendet.

[10] Auf dem „Instructions“ Tab unter Punkt 5 wird von „points of value“ geschrieben, dann in der Tabelle aber auf „benefit points“ verwiesen.

[11] Hohman, Luke. „pragmaticmarketing.com“ 08.11.2008. http://pragmaticmarketing.com/resources/why-prioritizing-your-agile-backlog-for-roi-doesnt-work?p=0

[12] Zacarias, Daniel. „foldingburritos.com.“ https://foldingburritos.com/product-prioritization-techniques/.

[13] Yatzeck, Elena. „Pragmatic Agilist.“ 10. 09 2014. http://pagilista.blogspot.de/2010/09/using-agile-to-optimize-value-of.html

Teile diesen Beitrag mit deinen Freunden!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *