Priorisiere nicht nach dem RoI! Warum WSJF besser ist.

RoI – das Wort allein ist ein Lackmustest. Wer’s kennt, weiß Bescheid. Wer’s nicht kennt, hat sich direkt mal betriebswirtschaftlich disqualifiziert. Oder ist es doch nicht so einfach und kein Grund jetzt sauer (pH-niedrig, denn das testet der Lackmustest eigentlich) zu werden?

RoI – der vermeintliche Klassiker

Der Return on Investment (RoI) beschreibt die minimale Form des Tauschhandels: Ich gebe etwas (Investment) und bekomme dafür etwas (Return). Ein noch akzeptabler Tauschhandel bringt mir so viel ein, wie ich gebe (Return/Investment = 1), ein guter stets mehr (Return/Investment ≥ 1). Wenn mein RoI negativ ist, dann gehe ich den Handel also nicht ein. Und wenn ich ihn eingehe, dann aus Doofheit. Oder?

Was bei den Diskussionen um den RoI gerne vergessen wird: Er ist eine Wette auf die Zukunft. Denn ein Investment muss ich erstmal tätigen und ein Return kann auf sich warten lassen. Und da liegt auch die erste Schwierigkeit mit dem RoI. Ohne einen Zeitbezug ist er nicht aussagekräftig. In der Finanzwirtschaft wird daher beispielsweise ein RoI YoY (die letzten 12 Monate, auch yearly trailing RoI genannt) oder ein RoI 3y (RoI über drei Jahre) angegeben. Auch dann ist noch die Basis wichtig, der Stichtag. Macht ja einen Unterschied, ob ich als Basis den 01. März 2020 oder den 01. Oktober 2020 ansetze. In der Finanzwirtschaft liegt der Bilanzstichtag nahe.

Im operativen Unternehmenskontext ist der RoI bei vielen Entscheidungen nicht passend, weil sowohl die Zeitpunkte der Bewertung, wie auch die betrachteten Zeiträume meist nicht übereinstimmen. Wie viel Aussagekraft hat ein RoI von 1.13 vom 11.02.2022 gegenüber einem RoI von 1.21 vom 14.11.2021?

Warum wird der RoI trotzdem genutzt?

Und doch ist der RoI weit verbreitet. Leider auch in der “agilen Welt”. Selbst, wenn er nicht so genannt wird. Da werden Backlog-Items nach Aufwand und Nutzen bewertet, manchmal sogar der Quotient aus beiden gebildet. Das ist dann der RoI!

Dumm nur, wenn die eine Schätzung drei Monate alt und die andere von gestern ist, die eine sich auf den Zeitraum von vier Monaten und die andere auf zwei Jahre bezieht. Insbesondere, wenn im Rahmen von rollierender Planung und emergenten Backlogs die Schätzungen über einen längeren Zeitraum entstehen. Jedem dürfte spätestens jetzt dämmern: Das passt hinten und vorne nicht.

Es gibt aber noch ein weiteres Problem: Aufwand ist nicht gleich Aufwand. Es gibt Tätigkeiten, die dauern zehn Minuten, dann gilt es drei Wochen zu warten, dann wieder fünf Minuten daran zu arbeiten. Ist der Aufwand jetzt mit 15 Minuten minimal oder mit über drei Wochen grösser als so mancher Sprint lang? Und müsste es dann nicht unterteilt (denglisch: gesplittet) werden, damit es in einen Sprint passt? Wie denn?

Ich höre die agilen Prediger schon Luft holen für den EINEN Satz: “Wir schätzen Aufwand aber relativ, nach Komplexität”. Entschuldigung, was ist das denn, dieses “Komplexität”? Drei Leute haben vermutlich drei Ideen dazu.

Aber zurück zum Thema. Wenn Aufwand und Dauer stark abweichen, dann wirkt sich dies negativ auf die Aussagekraft des RoI aus. Und mal ehrlich: Ein guter Teil der Zeit in der Entwicklung besteht aus Warten.

Warum also ist der RoI dennoch so verbreitet?

Es ist eben die einfachste Gegenüberstellung von Aufwand und Nutzen. Einfacher wäre es nur, Aufwand oder Nutzen anzusehen. Und es liegt nahe: Den Aufwand bewerten die Entwickler:innen, den Nutzen die Kund:innen. Aber sind die wirklich die Könige für diese Entscheidung? Mein klares Nein kannst Du hier nachlesen. Was haben die schon für eine Ahnung davon, welche unternehmensinternen Synergien ich mit einer Entscheidung schaffe? Dieses Argument einen Schritt weiter gedacht offenbart, dass es auch unternehmensintern selten die eine Expertin gibt für alle Facetten einer unternehmerischen Entscheidung gibt. Eine Person ist übrigens noch kein organisiertes Unternehmen, Alleinstehende zählen daher nicht.

Arbeit wird immer priorisiert. Aber wie wäre es gut?

Im letzten Artikel habe ich argumentiert, dass nicht ordnen nicht möglich ist. Wenn also immer priorisiert wird, der RoI aber leider nicht taugt, wie dann vorgehen?

Das ganze Gezeter gegen den RoI bringt uns nicht nach vorne. Es muss eine Alternative her, die den ökonomischen Rahmen in Unternehmen widerspiegelt.

Zum Glück gibt’s da einen passenderen ökonomischen Ansatz

Es gibt sogar ziemlich viele Untersuchungen, welche die Entscheidungsparameter sind, die Unternehmen prägen. Mit Blick auf die Produktentwicklung greife ich ein Modell heraus, dass im weiteren viele Anknüpfungspunkte bietet. Donald (Don) Reinertsen beschreibt im Buch “The Principles of Product Development Flow“, dass jede unternehmerische Entscheidung ökonomisch sein muss. In seinen eigenen Worten, aus seinem Buch zitiert:

While you may ignore economics, it won’t ignore you.

Don Reinertsen

Mit Don bin ich übrigens vor ein paar Jahren eine erkenntnisreiche Woche lang getourt, meine Erlebnisse habe ich hier beschrieben. Sein Ansatz geht von einer Mindestanzahl von Variablen aus, die miteinander verbunden (“interconnected”) sind. Diese können quantifiziert werden, aber immer nur im Zusammenspiel. Beinahe jede Entscheidung ist ein Trade-Off, manche mehr, manche weniger. In der Ökonometrie gibt es palettenweise Analysen dazu, sogenannte Sensitivitätsanalysen. Für uns geht es aber einfacher. Alle Variablen, die wir benötigen, finden sich im folgenden Bild:

Aus dem Zusammenspiel von

• Cycle Time (die Umsetzungszeit, nicht zu vertauschen mit der Lead Time, der Fertigstellungszeit mitsamt Wartezeiten),
• Product Cost (den direkten zurechenbaren Kosten),
• Development Expense (den mittelbar für die Entwicklung zurechenbaren Kosten),
• dem Produktwert (in der einfachsten Variante Preis, oftmals aber durch mehr Subvariablen geprägt)
• und dem stets unterliegenden, unmittelbaren wie mittelbaren Risiko

lässt sich eine Variable aggregieren, die in der Produktentwicklung alle Faktoren einer ökonomischen, ergo unternehmerischen Entscheidungen berücksichtigt. Diese Variable heisst Cost of Delay.

Cost of Delay als führende Kennzahl

Der Cost of Delay (CoD) quantifiziert die Kosten der Warteschlange. Zu jedem Zeitpunkt lassen sich also alle Ideen, die auf die Entwicklung warten bewerten. Daher Cost of Delay, also Verspätungskosten. Das Ziel ist es, diese Kosten möglich gering zu halten. Der CoD ist natürlich nicht die einzige Variable für unternehmerische Entscheidungen in der Produktentwicklung, sollte aber die erste sein:

If you only quantify one thing, quantify the cost of delay.

Don Reinertsen

Denn jede Entscheidung über die Priorisierung ist streng genommen eine Entscheidung der Sequenzierung: Die Reihenfolge der zu bearbeitenden Themen wird festgelegt. Dadurch wird zum einen der Wert der geplanten Themen (Upstream), zum anderen der Wert der Themen in Umsetzung (Downstream) beeinflusst. Und immer wenn etwas ganz Dringendes ganz schnell umgesetzt werden muss, verändert sich der Wert der Warteschlange. Ein Beispiel kann das besser veranschaulichen als viele Worte:

Drei Features (A, B, C) sollen umgesetzt werden – siehe die Tabelle auf der rechten Seite des Bildes.

Es ist verlockend mit C anzufangen (graues Feld unten links). Dauert schliesslich am längsten, also lieber mal früher loslegen. Dummerweise wirkt sich das auf A und B aus. Während C umgesetzt wird, fallen nämlich für diese beiden Verspätungskosten an, in Höhe von 160 Einheiten.

Also lieber mit A beginnen, wie in dem Teilbild oben links zu sehen, dann mit B weiter machen und zuletzt an C arbeiten. Dauert insgesamt gleich lang, aber die Verspätungskosten sind mit sieben Einheiten um das über 20-fache geringer!

Und während A und B umgesetzt werden, hat vielleicht sogar jemand eine Idee, wie C in kleinere Einheiten unterteilt werden kann.

Jetzt sind wir schon so weit und doch stellt sich die Frage: Wie kann ich das nun nutzen? Dafür führe ich WSJF ein.

WSJF – Weighted Shortest Job First – Wait what?

Weighted Shortest Job First (WSJF) das ist leider auf das erste, zweite und achte Mal nicht so leicht zu verstehen, wie RoI. Nichtsdestotrotz aber viel bedeutsamer. Warum erkläre ich jetzt.

Die Einheiten der Planung (z.B. Backlog-Items) in der Entwicklung/in Unternehmen sind meist weder gleich gross, noch gleich wertvoll. Und genau dann braucht es den WSJF.

Wenn der Aufwand gleich ist, aber der Wert unterschiedlich, dann kann ich nach den Verspätungskosten ordnen, also “Highest Cost of Delay First”.

Wenn der Wert gleich ist, aber die Aufwände unterschiedlich, dann kann ich nach dem kürzesten Aufwand (Cycle Time) umsetzen, sprich das was am schnellsten geht, zuerst fertig stellen (“Shortest Job First”). Klar, so bekomme ich früher meinen Wert geliefert. In einfachen Worten: Dauer bemisst sich nur nach der Umsetzungszeit.

Diese ist schliesslich ausschlaggebend, wenn ich überlege, ob ich die eine oder die andere Alternative umsetze. Falls allerdings die Cycle Time wesentlich durch Wartezeit (waiting time) wie im beispielsweise im Bild – weil ich auf ein:e Expert:in warten muss – bestimmt wird, dann verliert diese Aussagekraft. In der Praxis ist das erstens vorher nicht immer bestimmbar und zweitens im Rahmen der üblichen Schätzungenauigkeiten nicht entscheidend.

Den WSJF bestimmen, bedeutet unternehmerisch entscheiden

Der WSJF setzt sich also Cost of Delay und Cycle Time (Umsetzungsdauer, englisch Job Duration) zusammen.

Der Cost of Delay lässt sich unternehmensspezifisch aus dem oben gezeigten ökonomischen Rahmenwerk ableiten. Das Scaled Agile Framework (SAFe) schlägt zur Vereinfachung eine generische Formel vor:

In manchen Unternehmen können für den Cost of Delay auch Gewicht (zum Beispiel SpaceX, das Raumfahrtsunternehmen) oder Sicherheit (zum Beispiel Areva, der Nuklearreaktorhersteller) eine Variable bilden. Desweiteren können einzelne Faktoren höher gewichtet werden, zum Beispiel für eine Bank “Risk Reduction and/or Opportunity Enablement”. Bevor aufwendige Formelkonstruktionen gebaut werden, empfehle ich aber einfach mit der von SAFe empfohlenen Formel zu starten.

Bedeutung der Job Size als Hebel für die Priorisierung

Diese WSJF-Formel à la SAFe deckt auch den grössten Hebel auf: Job Duration. In dem Beispiel unten ist A dringender, wie auch bedeutsamer für “Opportunity Enablement and/or Risk Reduction”. Trotzdem ergibt die Rechnung, dass A nur als drittes angegangen werden sollte, weil die WSJF-Rechnung den niedrigsten Wert ausweist. Wie kann das geändert werden?

Option eins ist natürlich den Geschäftswert von A “hoch zu drehen” oder den von B und C “runter zu drehen”. Traue keiner Statistik/Berechnung, die Du nicht selbst gefälscht hast…

Im agilen Sinne gibt es aber einen besseren Hebel: Die Job Size verkleinern! Schon das Verkleinern auf einen Wert von 13 macht A zur ersten Wahl (WSJF=3.3). Die Überlegung sollte also stets sein: Wie kann ich ein ähnliches Ziel (CoD) mit weniger Aufwand erreichen.

Wenn das nicht mal agil, unternehmerisch und überhaupt einfach schlau ist!

Aber…

…WSJF hat auch Schwächen. Wie beim RoI ist auch beim WSJF stets der Zeitpunkt der Schätzung wichtig. Im Gegensatz zum RoI lässt der WSJF keine Betrachtung von Zeiträumen zu – wobei Prognosen eh eine Wette bleiben.

Und jetzt Du!

Wie sind Deine Erfahrungen mit dem WSJF?

Was würdest Du gern dazu erfahren? Wir könnten ja einen Online-Treff zum Thema starten, was denkst Du?