Andreas Diehl

Klarheit und Orientierung in der neuen und digitalen Arbeitswelt.

WSJF Methode – Ein einfaches Werkzeug zur Projektpriorisierung

WSJF Methode – Ein einfaches Werkzeug zur Projektpriorisierung 600 315 Andreas Diehl (#DNO)

WSJF (Weighted Shortest Job First) ist eine Methode zur Priorisierung deines Backlogs oder Projektportfolios. Ursprünglich stammt die WSJF Methode aus dem Scaled Agile Framework (SAFe). 

In diesem Artikel erkläre ich dir den Aufbau der WSJF Methode und zeige Dir, wie Du Du mit WSJF dein digitales Projektportfolio und dein Backlog priorisierst. Zudem bekommst Du eine gSheet bzw. Excel Vorlage, mit der Du direkt loslegen kannst.

Priorisierung als Basis für Wertmaximierung

Lieber ein bisschen alles, statt alles ein bisschen.
Andreas Diehl

Natürlich haben wir alle mehr Ideen als Kapazitäten. Und je länger die Liste unserer  Ideen ist, desto schwieriger und anstrengender ist es eine Priorisierung vorzunehmen. Denn Priorisierung bedeutet auch zu entscheiden, was erstmal nicht gemacht wird. Das kann eine unbequeme Aufgabe sein. Zum einen leiden wir alle unter Verlustaversion, also der Angst davor etwas zu verpassen. Zum anderen bedeutet priorisieren eine hohe Klarheit über die eigene Erwartungshaltung zu entwickeln. Das erfordert Zeit und könnte möglicherweise mit der unbequemen Einsicht enden, dass ich Vorhaben noch nicht umfassend genug verstanden habe, um sie gut priorisieren zu können. Das führt dann dazu, dass in vielen Organisationen lieber alles ein bisschen statt ein bisschen alles gemacht wird.

Priorisieren bedeutet Führung übernehmen

Dabei ist die konsequente Priorisierung anstehender Aufgaben eine wichtige Aufgabe. Das gilt für Dich in deiner Rolle als Product Owner oder Verantwortlicher für ein Projektportfolio. Denn mit einer klaren Priorisierung vermeidest Du eine Überforderung deiner Teams und deiner Organisation. Diese Form der Überlastung ist ganz im Sinne des Lean Management  eine Verschwendung (“Muri”), die es unbedingt zu vermeiden gilt. Und die WSJF Methode ist ein einfaches Werkzeug, um Klarheit zu erlangen und Priorisierung in der täglichen Praxis umzusetzen. Damit stellst Du sicher, dass Du nachhaltigere Werte für Kunden und deine Organisation schaffst. 

Vimeo

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von Vimeo.
Mehr erfahren

Video laden

Arbeiten mit WSJF im Kontext Portfolio-Priorisierung – Auszug aus dem #DNO Lunch & Learn „Digital Projekte“ (zur Aufzeichnung)

WSJF  – Weighted Shortest Job First (SAFe)

Mit der WSJF Methode identifizierst Du die Jobs, die die schnellste Wertgenerierung in Aussicht stellen. Dabei ist ein Job ein Epic, ein Feature, ein Projekt oder auch eine Capability (Voraussetzung für ein werthaltiges Projekt oder Feature).

Um den erwarteten Wert zu ermitteln, schaust Du mit WSJF zwei Dimensionen an, die Costs of Delay (CoD) und die Jobs Size. 

WSJF Methode im SAFe @ Scaled Agile, Inc.
WSJF im SAFe @ Scaled Agile, Inc.

Dabei sind die Costs of Delay vereinfacht gesagt eine Annäherung an den erwarteten Wert. Dagegen ist die Job Size eine Annäherung an den erwarteten Aufwand bzw. eine Aussage darüber, wie lange es braucht den Wert zu liefern. 

Schätzung des relativen statt absoluten Aufwands

Um die WSJF zu ermitteln, schätzt Du beide Dimensionen auf einer relativen Skala von 1-10 und teilst sie durcheinander. Abschließend priorisierst Du dein Portfolio nach den höchsten WSJF. 

CoD /WertJob Size /AufwandWSJF
Feature / Projekt A480,5
Feature / Projekt B221

Das heißt, obwohl das Projekt A einen höheren Wert verspricht, ist Projekt B höher zu priorisieren. Denn auch wenn Projekt B einen geringeren Wert verspricht, führt die deutlich geringere Job Size zu einem vorteilhafteren WSJF. Entsprechend ist Projekt B höher zu priorisieren. 

Das klingt zunächst vielleicht etwas kontraintuitiv, wird aber einleuchtender, wenn wir uns genauer anschauen, wie sich die “Costs of Delay” und die “Job Size” zusammensetzen.

Costs of Delay (CoD)

Die “Costs of Delay” sind eine Annäherung an den erwarteten Wert eines Features, eines Projektes oder auch einer benötigen Capability. Dabei setzen sich die Costs of Delay im SAFe Framework aus drei Faktoren zusammen: 

  1. Erwarteter Wert (“User-Business-Value”): Wie profitiert der Kunde (User Value), wie profitieren wir als Unternehmen (Business Value)? Welche nachteiligen Konsequenzen hat es, wenn wir mit der Fertigstellung warten, müssen wir z.B. mit einer Strafe rechnen?
  2. Wert Degression (“Time Criticality”): Gibt es also auf der Zeitachse feste Deadlines und damit verbunden die Gefahr, dass der Wert gar nicht mehr erzielt werden kann (weil z.B. ein wichtiger Kunde auf ein Feature wartet und bei Nicht-Bereitstellung auf eine andere Lösung gehen würde)? Hat eine mögliche Fertigstellung in xx Monaten noch den gleichen Wert wie heute?
  3. Risiken / Opportunities (“Risk Reduction – Opportunity Enablement Value”): Gibt es andere Risiken, die wir damit senken oder Gelegenheiten von denen dein Unternehmen profitieren kann? Gewinnen wir Einsichten, die uns für andere Vorhaben helfen?

Das heißt, mit den “Costs of Delay” ermittelst Du auf einer relativen Skala von 1-10 die Wirkung deines Vorhabens. Dabei werden deine “Costs of Delay” positiv beeinflusst von dem direkten Mehrwert für Kunden und Unternehmen und Randbedingungen, die es sinnvoll machen mit der Umsetzung besser jetzt als morgen zu starten. 

Job Size

Die “Job Size” ist eine Annäherung an den erwarteten Aufwand eines Features, eines Projektes oder auch einer benötigen Capability. Dabei unterstellt SAFe als agiles Framework, dass ein festes Team dauerhaft an der Erledigung einer Aufgabe arbeitet. Das heißt, die benötigte Zeit für die Umsetzung eines Vorhabens ist gleich der “Job Size” und eine valide Annäherung an die Kosten eines Vorhabens.

Wie auch die “Costs of Delay” bewertest Du die“Job Size” bzw. den erwarteten Aufwand auf einer Skala von 1-10. Dabei vergleichst Du den Aufwand relativ, d.h. nur mit anderen Vorhaben aus deiner Liste.

Mit der WSJF Methode arbeiten

Für die Ermittlung deiner WSJF findest Du in meiner Tabelle unterschiedliche Spalten mit einer Gewichtung. Die isolierte Betrachtung hat den Vorteil, dass Du dich genauer und zielgerichteter mit den unterschiedlichen Aspekten auseinandersetzt, statt viele Eindrücke in eine einzige Bewertung einfließen zu lassen. Sofern eine der Dimensionen für deinen Anwendungsfall nicht relevant ist, setze die Gewichtung einfach auf 0%.

Mit dem WSJF Template kannst Du ein Projektportfolio, dein Produktbacklog oder deinen MVP priorisieren. Mach Dir von der Tabelle eine Kopie oder lade sie herunter. Hinterlass deine Fragen dazu gerne in den Kommentaren

Cost of Delay ermitteln

Die “Cost of Delay” habe ich in meinen Template auf fünf Dimensionen aufgeteilt.

  • User / Customer Value: Was hat der User / Kunde davon?
  • Business Value: Wie profitiert dein Business?
  • Wert Degression: Wie zeitkritisch ist die Bereitstellung? Hat das Feature in 12 Monaten noch den gleichen Wert wie heute?
  • Risk Reduction: Kannst Du mit der Bereitstellung Risiken reduzieren? Wenn ja, steigert das den Wert.
  • Opportunity Enablement Value: Erschließt Du dir mit der Bereitstellung neue Opprotunities?

Job Size ermitteln

Wenn Du WSJF für die Produktentwicklung nutzt, kannst Du bezüglich der “Job Size” bei der Betrachtung aus dem SAFe Framework bleiben und mit der Tabelle direkt loslegen. Dahingegen brauchst Du für die Priorisierung deines digitalen  Service- und Projektportfolio eine erweiterte Betrachtung der “Job Size”.

“Job Size” für ein Service- und Projektportfolio 

Für die Ermittlung der “Job Size” deines digitales Service- und Projektportfolios habe ich neue Bewertungskriterien eingeführt. Denn anders als im SAFe Framework ist die Dauer der Umsetzung alleine keine repräsentative Größe für den erwarteten Aufwand. Dabei halte ich die folgenden Bewertungskriterien für relevant: 

  1. Entwicklungskosten / Sachkosten: Sofern Du keine Entwickler intern beschäftigst, trägst Du den relativen Aufwand für die Erstellung des Services ab.
  2. Interner Personalaufwand: Die relativen Aufwände der Fachabteilungen, um die Erstellung des Services mit Fach- und Prozesswissen zu begleiten. 
  3. Komplexität der Implementierung: Schließlich müssen digitale Services auch in die Abläufe integriert werden und Kunden müssen auf den neuen Service umgestellt werden. Meiner Erfahrung nach schlagen diese Aufwendungen am höchsten zu Buche.

Damit sind nach meiner Erfahrung die wichtigsten Dimensionen abgefragt, die einen Einfluss auf den zu erwarteten Aufwand haben. Diese Erweiterung findest Du so auch in der beigefügten Tabelle.

Fazit – Eine sehr einfache aber wirkungsvolle Priorisierung

Natürlich bieten Dir WSJF keine Glaskugel oder haben den Anspruch die “Wahrheit” abzubilden. Jedoch hast Du mit WSJF ein strukturiertes und transparentes Vorgehensmodell für die Priorisierung deiner Vorhaben. Nachdem Du die Bewertungsdimensionen der “Costs of Delay” und der “Job Size” in der Tabelle für dich gewichtet oder sogar ergänzt hast, kannst Du Bewertungen Feld für Feld diskutieren. Das heißt, es geht nicht mehr um einen “Mischmasch” von Einschätzungen, sondern um konkrete und sehr präzise Fragestellungen. Und ein einfacher Quotient gibt Dir am Ende eine Idee, welche Ideen und Vorhaben du am höchsten priorisieren solltest. 

Viel Erfolg dabei.

Artikel zum Download:

Weiterführende Artikel:

Mit Andreas arbeiten:

8 Kommentare
  • Andreas Diehl

    Danke David das freut mich. Gerne auch Anmerkungen zum / im gSheet, sofern Du damit auch arbeitest. Und hinterlasse auch gerne mal einen Erfahrungsbericht, was es euch bei der Priorisierung gebracht hat.

  • David Lupp

    Hallo Andreas, danke für Deinen Beitrag. Er hat mich bei der Einarbeitung in die Thematik gut unterstützt.
    Grüsse, David

  • Andreas Diehl

    Hi Bogu,

    danke für deine Frage(n). Völlig normal, dass dich das verwirrt.:) Ein paar Anmerkungen:

    Auch ohne die Methode sagt einem ja da schon der gesunde Menschenverstand, dass die Bereitstellung dieser Capability sein muss. Die Frage ist, ob es eine allg. Capability ist, von der mehrere Features / Epics profitieren oder eine dedizierte, die nur Teil des Features / Epics ist, das ihr mit WSJF hoch priorisiert habt.

    In dem letzten Fall, ist es Teil des Features / Epics und müsste imo gar nicht gesondert priorisiert werden. Sondern gehört dann eben einfach zu diesem Feature / Epic. Da würde ich mehr eher anschauen, ob du das nicht noch kleiner schneiden und nochmal mit WSJF priorisieren kannst.

    Sofern es eine allg. Capability ist, würde das innerhalb der WSJF Methode einen hohen Wert im Bereich „Risiken / Opportunities“ bedeuten. D.h. Du hast zwar keinen direkten User Value, aber hohen Business Value und hohen „Opportunity Enablement Value“. Das heißt einen hohen Wert bzw. Cost of Delay.

    Aber ich wäre da auch nicht päpstlicher als der Papst. SAFe und aus dem Framework stammt die Methode ja, ist für große Teams / Organisationen, die dedizierte Teams haben, die nur an der Bereitstellung solcher Capabilities arbeiten. Wichtiger ist die Diskussion die ihr über eure Priorisierung führt. Denn WSJF ist ja auch nur ein Modell, das versucht abstrakte und komplexe Sachverhalte „begreifbar“, besprechbar und damit bewertbar zu machen. Der Erkenntnisgewinn aus eurer Diskussion, könnte für euch sein, dass ihr erst dadurch Transparenz darüber gewonnen habt, wie kritisch die Capability ist, dass ihr vielleicht die Organisation eurer Epics überdenkt, dass ihr die Dimension „Opportunity Enablement Value“ unterschätzt oder auch einfach, dass gesunder Menschenverstand besser als jede Methode ist.:)

    Ich hoffe das hilft Dir. Wenn nicht schreib mir gerne eine E-Mail.

    Viele Grüße,
    Andreas

  • Bogu

    Hallo Andreas,

    ich habe mich gefreut, über diese Methode in Deinem Blog zu lesen. Nun habe sie in einem Kontext ausprobiert, in dem ich gemerkt habe, dass sie mich leider zugleich verwirrt hat. Ich hatte Idee/Probleme aus einem Brainstorming mit einem Team bewertet. So weit, so gut. Nun haben wir aber festgestellt, dass die Themen einander bedingen. Auf Grund der Abhängigkeiten scheint mir nun die Priorisierung wenig sinnvoll. Hast Du eine Idee, wie man vorgehen könnte, wenn man noch Abhängigkeiten berücksichtigen muss?

    Viele Grüße
    Bogu

  • Andreas Diehl

    Hi Christian,

    folgende Ergänzungen / Überlegungen dazu:

    Teamübergreifend brauchst Du nach meinem Verständnis nur eine Vergleichbarkeit, sofern die Teams gemeinsam an einem Backlog arbeiten und auf Basis der Priorisierung mit der WSJF Methode dann flexibel auf die jeweiligen Stories allokiert werden. Sofern jedes Team isoliert in seiner eigenen Domäne arbeitet, ihre eigenen Backlogs haben, Team A ohnehin keine Aufgaben von Team B übernehmen kann, bräuchte es ja keine Vergleichbarkeit.

    Wenn dem also ist, dass mehrere Teams an einem Backlog arbeiten, dann würde ich das über ein gemeinsames Planning lösen bzw. Stories auch mal quer schätzen lassen. Dabei kannst Du für die Schätzung des Aufwand natürlich einfach auch auf Storypoints zurückgreifen und damit den relativen Aufwand schätzen. Und durch das Festlegen einer Referenzstory und Arbeiten mit der Fibonacci Reihe würde das schon deutlich „entschärft“, erst recht wenn Du es mit gemeinsamen Plannings definierst und / oder Schätzungen mal quer checken lässt. Bzw. würde ich das Team dann auch dran arbeiten lassen, die am billigsten schätzen, das regelt sich dann im Laufe der Zeit von alleine.:) Unabhängig davon wird der Value ja ohnehin über den / die PO’s geschätzt.

    Das mal als erster Impuls. Kritische Frage ist natürlich immer die gesamte Teamgröße und ob die ein gemeinsames Planning machen können. Und trotz allem geht es ja nie darum die „Wirklichkeit“ zu modellieren. Sondern auf Basis eine guten Diskussion zu einer sinnvollen Priorisierung zu kommen, um schnellstmöglich den meisten Wert zu liefern.

    Ich hoffe das beantwortet deine Frage. Wenn nicht schreib mir gerne eine E-Mail und lass uns telefonieren.

    Viele Grüße,
    Andreas

    PS: Wenn du den Aufwand über Storypoint schätzt, würde ich beim Wert bis 100 gehen (in 10er Schritten), damit Du nicht mit Nachkommatsellen balancieren musst.

  • Christian S.

    Hallo Andreas,
    vielen Dank für diesen spannenden Beitrag.
    Wie könnte man die Metrik noch optimieren, so dass auch Team-übergreifend vergleichbare Werte entstehen?
    Ein relativer Wert von 1-10 ist i.d.R. eine subjektive Einschätzung. Hier wäre es sinnvoll, wenn man den jewiligen Werten einen konkreten Wertebereich zuweisen könnte.
    Gibt es Erfahrungswerte oder Beispiele, anhand derer die Werte 1-10 noch weiter spezifiziert wurden?
    Danke und Gruß
    Christian

  • Andreas Diehl

    Hi Benjamin,

    wenn du nur interne bzw. Personalkosten hast, dann würde sich das in meinem Verständnis wie folgt auswirken

    Tab A: Projektportfolio -> Spalte G streichen bzw. auf 0% setzen
    Tab B: Produktentwicklung -> keine Änderung

    Also, wenn Du Produkte mit internen Ressourcen entwickelst und auf Tab B unterwegs bist, dann verteilen sich Personalkosten auf Spalte G (Aufwand technische Entwicklung) und Spalte H (Aufwand Konzeption (incl. Design)).

    Macht das so Sinn für dich?

    Viele Grüße,
    Andreas

  • Benjamin K.

    Hallo Andreas

    Danke für den spannenden Beitrag über die WSJF Methode. Diese Methode war mir bisher unbekannt, werde dies aber baldmöglichst versuchen in der Praxis anzuwenden.

    Eine Frage habe ich dazu. Wie definieren/unterscheiden sich die folgenden beiden Bewertungskriterien, wenn die Entwicklung zu 100% intern in unserem Unternehmen erfolgt:
    – Entwicklungskosten / Sachkosten
    – Interner Personalaufwand

    Besten Dank für die Rückmeldung.
    Grüsse, Benjamin

Hinterlasse eine Antwort

Ihre Email-Adresse wird nicht veröffentlicht.