Mit der WSJF-Methode priorisieren

Als Product Owner ist es Deine Aufgabe, Dein Product Backlog in einer Reihenfolge zu priorisieren, die den Wert Deines Produktes maximiert. Neben dem bekannten MoSCoW-Prinzip existiert die WSJF-Methode (Weighted Shortest Job First), die ich Dir hier vorstellen möchte. Sie ist insbesondere dann gut geeignet, wenn es darum geht, sogenannte Verzögerungskosten (Cost of Delay) zu vermeiden.

Weighted Shortest Job First (oder kurz WSJF) ist eine Methode, die im Buch The Principles of Product Development Flow von Donald Reinertsen das Licht der Welt erblickte. Sie ist mittlerweile – wie vieles andere – ins SAFe-Framework übernommen worden, wurde allerdings nicht für SAFe entwickelt.

Die Grundidee der WSJF-Methode basiert jedoch auf dem Prinzip der Verzögerungskosten, die schon im Lean Management oder Kanban genutzt wurden (und werden).

Die Funktionsweise der WSJF-Methode ist recht einfach zu verstehen, wenn Du einmal davon ausgehst, dass Du für zwei unterschiedliche Projekte die gleichen Einnahmen generierst, diese Projekte aber unterschiedlich lange dauern werden.

Wenn Du beispielsweise sowohl mit Projekt A als auch mit Projekt B 10.000 € Umsatz generierst, aber Projekt A 8 Sprints dauern wird, Projekt B jedoch nur 5 Sprints, dann wirst Du Dich logischerweise dazu entschließen, Projekt B zuerst anzugehen.

Denn im Sinne eines kontinuierlichen Geldflusses wäre es ja gut, möglichst früh Umsatz zu generieren.

Weil Du Projekt B vorziehst, entstehen für Projekt A Verzögerungskosten. (Weil es ja auf Projekt B warten muss.) Selbst für Projekt B entstehen Verzögerungskosten, weil der Umsatz erst dann entsteht, wenn es abgeschlossen ist. (Auch dann, wenn Du es zuerst durchführst.)

Verzögerungskosten entstehen deshalb zwangsläufig, weil ein Unternehmen nicht alles gleichzeitig machen kann.

Um die Verzögerungskosten zu berechnen, musst Du nun lediglich den Wert des Projektes mit der Zeit multiplizieren, die es dauert, das Projekt umzusetzen.

Führst Du zuerst Projekt A durch, entstehen für dieses Projekt 80.000 € Verzögerungskosten (8 Sprints × 10.000 €). Für Projekt B entstehen hingegen 130.000 € Verzögerungskosten, weil es erst nach 13 Sprints abgeschlossen ist.

Insgesamt entstehen deshalb 210.000 € Verzögerungskosten.

Anders sieht es aus, wenn Du zuerst Projekt B durchführst und danach Projekt A abschließt. Die Cost of Delay sind durch die veränderte Reihenfolge niedriger.

Projekt B erzeugt 50.000 € Verzögerungskosten. (5 Sprints × 10.000 €), da es zuerst durchgeführt wird. Für Projekt A fallen 130.000 € an, da es nach 13 Sprints fertiggestellt ist.

Insgesamt entstehen bei dieser Reihenfolge deshalb nur 180.000 € Verzögerungskosten.

Der Nachteil dieser Vorgehensweise wird deutlich, wenn Du Dir vorstellst, dass Du 5 (oder sogar mehr) Projekte hast, die unterschiedliche Einnahmen generieren und eine unterschiedliche Dauer haben.

Denn Du müsstest jedes Mal, wenn Du die Reihenfolge der Projekte veränderst, die Cost of Delay für jedes Projekt neu berechnen.

Ziemlich umständlich.

Zur Veranschaulichung erweitern wir unser Beispiel deshalb einmal um die Projekte C, D und E.

An dieser Stelle kommt die WSJF-Methode ins Spiel. Denn mathematisch gesehen ist es das Gleiche, wenn Du Wert durch Zeit dividierst. So kannst Du direkt erkennen, wie hoch die inhärenten Verzögerungskosten jedes Projektes sind. Dadurch erhältst Du einen konkreten Zahlenwert, mit dessen Hilfe Du Projekte (oder Features) priorisieren kannst.

Je höher der WSJF-Wert ist, desto höher sollte das Projekt oder Feature priorisiert sein.

Hier siehst Du die WSJF-Werte für Projekt A und Projekt B.

Weil bei Projekt B der WSJF höher ist, solltest Du es vor Projekt A umsetzen. Diese Reihenfolge erzeugt (wie wir oben gesehen haben) die geringsten Verzögerungskosten.

Nehmen wir die anderen Projekte noch mit dazu, dann ergibt sich folgende Backlog-Priorisierung anhand der WSJF-Methode.

Im Lean Management oder auch in Kanban nennt sich die WSJF-Methode auch Cost of Delay Devided by Duration (kurz CD3). In SAFe wird die Variable Wert jedoch nicht nur anhand des Umsatzes berechnet, sondern folgendermaßen:

Cost of Delay = User-Business Value + Time critically + Risk reduction-opportunity enablement value

Jede dieser drei Größen wird dabei mit Hilfe einer angepassten Fibonacci-Reihe geschätzt und erst die Summe aller Werte stellt die Cost of Delay dar.

Wenn Du so möchtest, ist die Berechnung des CD3-Wertes eine besondere Form der WSJF-Methode. (Manche sind allerdings der Ansicht, dass es genau umgekehrt sei.)

Vereinfacht gesagt, ist es egal, ob Du Deine Cost of Delay nun anhand von (noch) nicht erzieltem Umsatz berechnest (und damit die „originale“ CD3-Methode wählst) oder ob Du die komplizierte Formel aus SAFe nutzt. Das dahinterliegende Grundprinzip ist immer identisch.

Jede Formel berechnet ^Wert/_Zeit.

Was für Dich und Dein Business nun genau Wert ist, kannst Du deshalb nur selbst entscheiden. (Gleiches gilt für die Zeiteinheit: Du kannst dazu Tage, Stunden, Sprints, Monate, ja sogar Story Points verwenden.)

Wenn Du beispielsweise eine App entwickelst, kannst Du auch 1 bis 5 Sterne für den Nutzen neuer Features vergeben und die Anzahl der Sterne durch die Tage dividieren, die es dauert, dieses Feature zu programmieren.

Es ist völlig unerheblich, ob Du ^Sterne/_Tage oder ^{Projektumsatz}/_Sprints rechnest. Wichtig ist, dass Du es immer gleich tust.

Das Beste ist es deshalb, gemeinsam mit Deinen Stakeholdern zu besprechen, was für Euch Wert bedeutet, damit Ihr Euch auf eine gemeinsame Formel einigen könnt. Es ist vollkommen in Ordnung, mit einer ersten Formel zu beginnen und diese später anzupassen, weil Ihr bemerkt, dass sie noch nicht ausreichend war.

Ich hoffe, ich konnte Dir den Nutzen der WSJF-Methode ein wenig näher bringen. Die Unterschiede zur CD3-Formel aus dem Lean Management sind meiner Meinung nach nicht besonders groß. Mir war in diesem Artikel wichtig, dass Du das Grundprinzip der Verzögerungskosten verstehst, auf dem beide Varianten basieren.

Wie Du nun genau die Cost of Delay für Dein Projekt oder Produkt berechnest, ist – meiner Meinung nach – erst einmal zweitrangig, um das Prinzip auf Deine Backlog-Priorisierung anzuwenden. Aber vielleicht bist Du ja anderer Meinung? Dann schreib mir gerne einen Kommentar hier unten auf der Seite und tausche Dich mit mir darüber aus. Ich freu mich, von Dir zu hören!