Start Führung WSJF Methode – Ein einfaches Werkzeug zur Projektpriorisierung
dno logo

10. Februar 2020

von

Andreas Diehl

WSJF Methode – Ein einfaches Werkzeug zur Projektpriorisierung

10. Februar 2020

Führung

Wofür priorisieren – 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 eine Priorisierung. Denn Priorisierung bedeutet Entscheidungen zu treffen. Nämlich darüber, was Du präferierst, was erstmal nicht gemacht wird oder auch welche Vorhaben Du einstellst. Das ist aus mehreren Gründen eine unbequeme Aufgabe. Zum einen leiden wir alle unter Verhaltensheuristiken, die zu suboptimalen Entscheidungen führen.  Zum anderen erfordert eine gute Priorisierung , dass Du eine hohe Klarheit über dein Vorhaben gewinnst, den Kontext und die Domäne verstehst, um überhaupt entscheiden zu können. 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.

Konzeptionelle Grundlagen der WSJF Methode

Mit der WSJF Methode identifizierst Du die Jobs, die die schnellste Wertgenerierung in Aussicht stellen. Ein “Job” steht dabei stellvertretend für ein Feature, ein Epic, eine Capability oder ein Projekt. Zu jedem Job berechnest Du den WSJF aus den Costs of Delay (CoD) und der Jobs Size. Je höher der WSJF Wert, desto höher wird der Job priorisiert.

WSJF ist das Verhältnis der “Cost of Delay” und der “Job Size”. Cost of Delay entspricht dabei dem Wert und Job Size der Zeit bzw. dem Aufwand.
WSJF ist das Verhältnis der “Cost of Delay” und der “Job Size” 

Costs of Delay (CoD)

Die Costs of Delay sind vereinfacht gesagt eine Annäherung an den erwarteten Wert. 

  1. User- und  Business-Value: Wie profitiert der Kunde (User Value), wie profitieren wir als Unternehmen (Business Value)? 
  2. 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. Risk Reduction und / oder Opportunity Enablement: Gibt es Risiken, die wir mit einer Umsetzung des Job senken? Bauen wir mit der Umsetzung neue Kompetenzen oder technische Capabilities auf, von denen andere Vorhaben profitieren? 
Die Cost of Delay im Scaled Agile Framework (SAFe). Cost of Delay ist der User-Business Value + Time Critically + Risk Reduction and/or Opportunity Enablement.
Die Cost of Delay im Scaled Agile Framework (SAFe) 

Das heißt, deine “Costs of Delay” werden positiv beeinflusst von dem direkten Mehrwert für Kunden und Unternehmen und zusätzlichen 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 bzw. eine Aussage darüber, wie lange es braucht den Wert zu liefern. Dabei unterstellst Du der ursprünglichen Formulierung der WSJF Methode in Anlehnung an agile Spielregeln, dass ein festes Team dauerhaft an der Umsetzung arbeitet. Unter diesen Voraussetzungen ist die benötigte Zeit für die Umsetzung eines Vorhabens eine valide Annäherung an den Aufwand eines Vorhabens. Da diese Voraussetzung jedoch in vielen Situationen nicht gegeben ist, zeige ich Dir weiter unten, wie Du die Job Size mit ein paar Erweiterungen auch für deine Vorhaben ermitteln kannst. 

Aufwand und Wert schätzen – Relative statt absoluter Schätzung

Die dritte konzeptionelle Grundlage der WSJF Methode ist die relative Schätzung der Cost of Delay und der Job Size. Das heißt, Du schätzt für alle zu priorisierenden Jobs die Cost of Delay und die Job Size auf einer relativen Skala von 1-10. Die Bewertungsskala solltest Du je nach Anzahl der zu bewertenden Jobs erweitern.

Nachdem Du für alle Jobs die Cost of Delay und die Job Size relativ zueinander geschätzt hast, berechnest Du den WSJF Wert und priorisierst dein Portfolio nach dem höchsten WSJF Wert. Das folgende Beispiel ist eine einfache Darstellung in der Job A und Job B priorisiert werden. 

Cost of DelayJob SizeWSJF
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. 

Mit der WSJF Methode arbeiten

Kommen wir zur Frage, wie Du WSJF für Dich arbeiten lassen kannst. Ich habe im praktischen Einsatz gemerkt, dass ein paar zusätzliche Schritte helfen, um die oben skizzierten konzeptionellen Grundlagen auch über die Produkt- und Softwareentwicklung hinaus erfolgreich anzuwenden. 

Ich zeige Dir nun, wie Du WSJF für deinen Kontext anpasst. Mach Dir vorher am besten eine Kopie des WSJF Template und hinterlasse deine offenen Fragen zur Vorlage oder Vorgehen gerne in den Kommentaren

Schritt 1: Bewertungsrahmen für die “Cost of Delay” definieren

Zunächst definierst Du den Bewertungsrahmen für die “Cost of Delay”. Ich habe mich in meinem Template dazu entschieden den User- und Business Value getrennt abzufragen. Mit einer differenzierten Betrachtung der Kunden- und Unternehmensinteressen motivierst Du eine Gruppe zu einer systematischen Auseinandersetzung mit den Kundenbedürfnissen. Damit sinkt das Risiko am Kunden vorbei zu arbeiten und nur die Unternehmensinteressen zu verfolgen. Außerdem frage ich die Dimensionen Risiko und Opportunity Enablement getrennt ab. Das kann gerade in Industrien Sinn machen, die sich durch eine hohe Regulatorik auszeichnen. In Summe führt das zu fünf Dimensionen, um die “Cost of Delay” zu ermitteln. 

  1. Customer Value: Welchen Wert generiert das Vorhaben für den Kunden?
  2. Business Value: Welchen Wert generiert das Vorhaben für unser Unternehmen?
  3. Wert Degression bzw. Time Criticality:  Ist die Umsetzung zeitkritisch? D.h. würde eine spätere Umsetzung weniger Wert schaffen?
  4. Opportunity Enablement: Schaffen wir mit diesem Job wichtige (technische) Voraussetzungen, um erfolgreich an anderen Vorhaben / Jobs zu arbeiten?
  5. Risikoreduktion: Gibt es irgendwelche Risiken, die wir mit der Umsetzung senken? Laufen wir z.B. Kunden zu verlieren oder wichtige regulatorische oder formale Vorgaben nicht einzuhalten?

Die “Cost of Delay” in deinem Team besprechen

Um die Bewertung der “Cost of Delay” für deinen Anwendungsfall anzupassen, solltest Du folgende Fragen beantworten: 

  1. Welche der fünf Dimensionen sind für uns relevant?
  2. Wie gewichten wir die einzelnen Dimensionen?
  3. Welche Leitfragen sind für uns ergänzend zu den oben genannten in den einzelnen Dimensionen repräsentativ?

Damit hast Du einen Bewertungsrahmen geschaffen, um die “Cost of Delay” für dein Backlog oder Portfolio zu schätzen.

Schritt 2: Bewertungsrahmen für die “Job Size” definieren

Die “Job Size” habe ich in meinem Template um zwei Dimensionen erweitert, um sie auch über die Softwareentwicklung hinaus und erst recht für Vorhaben im Zuge der digitalen Transformation anwendbar zu machen. Denn der Aufwand deines Teams ist wie in der ursprünglichen Darstellung der WSJF Methode nur unter folgenden Voraussetzungen ein ausreichendes Kriterium für die Job Size:

  1. Du kannst alle Leistungen in deinem Team selbstwirksam erbringen
  2. Du hast “end-to-end” Verantwortung für die erfolgreiche Implementierung / Platzierung des Vorhabens.

Sofern eine dieser Bedingungen verletzt wird, brauchst Du in meinem Verständnis weitere Dimensionen für eine gute Schätzung der “Job Size”, erst recht für die Umsetzung von Maßnahmen im Kontext der digitalen Transformation. Deswegen habe ich mich entschieden für die “Job Size” folgende Aspekte zu schätzen:

  1. Aufwand der Umsetzung (im Team)
  2. Komplexität der Implementierung: Wenn Du z.B. neue Abläufe oder Prozesse implementierst oder den Kunden auf digitale Bestelleingänge umstellen willst, muss das nicht auf Gegenliebe stoßen. D.h. nicht alleine der Aufwand für die Umsetzung eines Vorhabens ist entscheidend, sondern vor allem der Aufwand es erfolgreich “auf die Straße zu bringen”. Ich beobachte, dass dieser Aufwand doppelt so hoch ist wie der Aufwand der Umsetzung.
  3. Externe Sach- und Entwicklungskosten: Schließlich kann es sein, dass Du bzgl. der Umsetzung auch auf externe Hilfe angewiesen bist.

Wie auch bei den “Cost of Delay” entscheidest Du im Team, welche Dimensionen ihr betrachten, wie ihr sie gewichten wollt und welche konkreten Leitfragen maßgeblich sind.

Schritt 3: Relativen Aufwand schätzen

Nachdem Du also einen Bewertungsrahmen für die “Cost of Delay” und die “Job Size” definiert hast, beginnst Du mit der eigentlichen Arbeit in deinem WSJF Template. Dabei gehst Du wie folgt vor. 

  1. Backlog listen:

    Zunächst listest Du dazu alle “Jobs” die Du priorisieren willst. Das können Projekte, Features oder auch Epics sein. Wichtig ist nur, dass Du nicht Äpfel mit Birnen vergleichst, also z.B. ein Projekt mit einem Feature. Das heißt, in dieser Liste dürfen nur Jobs des gleichen Typs stehen. 

  2. Bewertungsskala definieren

    Typischerweise schätzt Du auf einer Skala von 1 bis 10. Aber natürlich sollte die Skala in Relation zur Anzahl deiner Jobs aus Schritt 1 stehen. Definiere also eine passende Bewertungsskala.

  3. Bewertungsregeln definieren

    Bei Teams und Gruppen, die “stark zur Mitte” tendieren, kann es zudem sinnvoll sein eine Regel zu etablieren, dass jeder Wert nur einmal vergeben werden darf. Eine zweite Regel könnte sein, dass MIN und MAX Wert der Skala unbedingt vergeben werden müssen.

  4. Erste Dimension auswählen:

    Startet die Priorisierung mit der ersten Dimension z.B. “Customer Value”.

  5. Ausreisser suchen

    Entscheidet euch innerhalb dieser Dimension für den Job mit dem höchsten Wert. Im Anschluss definiert ihr den Job mit dem niedrigsten Wert.

  6. Alle Jobs bewerten:

    Nachdem Du mit deinen Ausreißern Referenz geschaffen hast, bewertest Du alle Jobs der ausgewählten Dimension in Relation dazu. Du bist fertig, wenn alle Jobs in Bezug auf die aktuelle Dimension (in diesem Beispiel “Customer Value”) einen Wert haben. 

  7. Alle Dimension bewerten

    Im Anschluss gehst Du auf die nächste Dimension, z.B. “Business Value” und wiederholst die Schritte 5. und 6. Wiederhole das Vorgehen für alle deine Dimensionen. 

Schritt 4: WSJF Wert final besprechen

Nachdem Du alle Jobs in allen Dimensionen bewertet hast, erhältst Du einen eindeutigen WSJF Wert. Du kannst deine Tabelle nun nach dem höchsten Wert sortieren. Dieses Vorhaben ist das Feature oder Projekt mit der höchsten Priorität. Es kann und wird passieren, dass sich dieser  Einsicht weitere Diskussionen anschließen. Da meldet sich unter Umständen das unbewusste Erfahrungswissen. Das heißt, “intuitiv” passt da was nicht. Geht ruhig zurück in die Diskussion, versucht zu verstehen, was ihr übersehen habt und wie es zu dem WSJF Wert kam. Wichtig ist nur, dass Du nun nicht anfängst, wieder alles in Frage zu stellen. Viele Leute haben an dieser Stelle Probleme damit, dass nun Dinge erstmal nicht gemacht werden. Das darfst Du als Product Owner oder Verantwortlicher für ein Portfolio aushalten und dann eine Entscheidung treffen. Schließlich hast Du nun die Jobs ausgewählt, die die schnellste Wertgenerierung in Aussicht stellen.

Fazit – WSJF ermöglicht strukturierte Diskussionen und eine wirkungsvolle Priorisierung

Der große Vorteil der WSJF Methode ist weniger der eindeutige Wert, als vielmehr die Diskussion, die Dich zu diesem Wert führt. Dabei ermöglicht die sehr granulare Betrachtung in Verbindung mit der relativen Schätzung eine sehr zielgerichtete und strukturierte Diskussion mit einem eindeutigen Ergebnis. Zudem kannst Du in diesen Prozess zahlreiche Personen involvieren, um viele Sichtweisen in deine Priorisierung einfließen lassen. Damit hast Du ein transparentes und vor allem kollaboratives Vorgehensmodell für die Priorisierung deiner Vorhaben geschaffen.

Viel Erfolg dabei.

Signatur des Blog Autors Andreas Diehl.

Zusätzliche Ressourcen

Tool

WSJF Template

Das WSJF Template ist eine Arbeitsvorlage, um ein Projektportfolio oder Produktfeatures mit der WSJF Methode strukturiert zu priorisieren. Im dazugehörigen Arbeitsblatt findest Du eine genaue Anleitung zur Arbeit mit der WJSF Methode. Wenn nichts mehr hilft, können wir das WSJF Template auch gerne in einem Workshop gemeinsam mit Leben füllen.

Cover: Screenshot gSheet #DNO WSJF Template

Über den Autor

Profilbild von Andreas Diehl

Andreas Diehl

Mein Name ist Andreas Diehl. Ich blogge und berate zu OKR, digitaler Unternehmens- und agiler Organisationsentwicklung. Futter für meine Beiträge sind 22 Jahre Digital Business und Erfahrungen aus über 12 Jahren Beratung.


11 Antworten

  1. Avatar von Carolin
    Carolin

    Hi Andreas,
    die Kopie deines WSJF Templates ist nicht mehr verfügbar. Könntest du es bitte erneut zur Verfügung stellen?

  2. Avatar von Andreas Diehl
    Andreas Diehl

    Hi Jelle, danke fürt den Hinweis. Das haben sie auf der SAFe Schulung nicht erwähnt oder ich habe nicht richtig zugehört.:) Aber ist natürlich gar nich in meinen Sinne da irgendwas zu unterschlagen. Don Reinertsen kenne ich namentlich als Autor von “The Principles of Product Development Flow”. Hast Du da zufällig eine genauere Quelle, das Buch habe ich noch nicht gelesen.:) Oder ist das auch dort beschrieben, dann ziehe ich das auf meiner Leseliste vor.

  3. Avatar von Jelle

    Hallo Andreas,

    ich bin Agile Coach. Seit 20 Jahre. WSJF is von SAFe gestohlen. SAFe hast sich vieles angeeignet. Das ist sehr bedenklich und auch nicht gut für deinen Ruf, wenn Du es kritiklos übernimmst.

    Du möchtest vielleicht nach Don Reinertsen Googlen.

    Jelle van Wieringen

  4. 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.

  5. Avatar von David Lupp
    David Lupp

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

  6. 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

  7. 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

  8. 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.

  9. Avatar von Christian S.
    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

  10. 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

  11. Avatar von Benjamin K.
    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

Schreibe einen Kommentar

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

#DNO Newsletter

Ein wöchentlicher Newsletter zu moderner Unternehmensentwicklung und Führung.