WSJF-Methode: Wer viel misst, misst Mist!

Etwas messen kann man nur mittels Zahlen und Maßeinheiten. Sobald etwas gemessen wird, werden Menschen durch die Objektivierung notwendigerweise trivialisiert. Dinge messbar zu machen bedeutet, die Unbestimmtheit zu tilgen. Ohne Unbestimmtheit keine Komplexität, kein Leben. Dementsprechend sollte ausschließlich in Kontexten gemessen werden, wo alle Beteiligten damit leben können, dass die Wirkung von und auf Menschen vernachlässigt wird. Denn eine Wirkung von und auf Menschen ist immer vorhanden, alleine durch die Tatsache, dass es mindestens einen Menschen geben muss, der die Messungen durchführt.

Dieses Eingangsstatement möchte ich näher beleuchten und zwar anhand eines bekannten Werkzeugs: des WSJF-Score. Der WSJF-Score ist ein Werkzeug für das Priorisieren des Backlogs. Als solches ist es in meinen Augen weder gut noch schlecht. Ich kritisiere hier auch nicht das Werkzeug selbst, sondern dessen unbedarften Gebrauch.

Was ist der WSJF-Score?

„Weighted Shortest Job First” (WSJF) ist eine gängige Kennzahl für die Priorisierung des Backlogs. Don Reinertsen nutzt beispielsweise diesen Score, um in seiner Reinertsen-Matrix die Backlog-Items zu sortieren. Kurz gesagt besagt dieser Score, dass immer jene Sache zuerst erledigt werden sollte, die den höchsten Wert liefert und die Entwicklungs- oder Auftragspipeline für die kürzeste Zeit blockiert. Diese Herangehensweise erlaubt es, so schnell und so viel Wert wie möglich zu liefern.

Praktisch formuliert: Es ist besser, 3000 Euro in einem Monat zu bekommen als 6000 Euro für die Arbeit eines Jahres. Ich kann ja immer noch die 6000 Euro anstreben, wenn ich erst einmal die 3000 Euro eingefahren habe. Wenn ich mich aber zuerst auf die Tätigkeiten stürze, mit denen ich vermeintlich 6000 Euro ernte, muss ich schauen, wie ich dann ein Jahr ohne Geld auskomme.

Wie wird WSJF berechnet?

Um die optimale Backlog-Position für ein bestimmtes Element herauszufinden, wird geschätzt, wie sich die Erledigung des Elements („Wert“) auswirkt. Dieser Wert wird durch die Investition in das Element („Größe“) geteilt. Anschließend werden die Elemente zueinander in Relation gesetzt.

Für die Schätzung von Wert und Größe wird oft vorgeschlagen, die „agile“ Fibonacci-Skala zu verwenden: 1, 2, 3, 5, 8, 13, 20, 40, 80 ... Die Idee dahinter ist, dass jede nachfolgende Zahl ein bisschen mehr, aber nicht ganz doppelt so viel ist wie die vorherige: Eine 13 ist also ein bisschen mehr als 8, aber nicht ganz 20. Da es keine Zahlen dazwischen gibt, kann ich, wenn ich nicht sicher bin, ob ein Backlog-Item eine 8 oder 13 ist, eine von beiden wählen, da diese beiden Zahlen benachbart sind und ihr Unterschied als geringfügig angesehen wird.

Für jedes Backlog-Item werden der Wert und die Größe also anhand der Fibonacci-Zahlen geschätzt.

  • Für die Ermittlung des „Wertes“ lassen sich verschiedene Kriterien heranziehen: Der Wert, den der Benutzer dem Backlog Item zumisst oder der Geschäftswert, Zeitkritikalität, Befähigung und/oder Risikominderung. Die Übung sollte aber nicht zu einer Wissenschaft werden: Es handelt sich hier um einen mutmaßlichen Wert. Subjektivität lässt sich bei der Schätzung nicht verhindern. Die gefundene Zahl kommt nun also in den Zähler der Gleichung.
  • Die „Größe“ wird typischerweise in Story Points gemessen. Unabhängig davon, was ein Story Point in einer Organisation bedeutet oder wie er erzeugt wird, erhalten wir eine andere Zahl – den Nenner der Gleichung.

Der WSJF-Score wird berechnet, indem der „Wert“ durch die „Größe“ geteilt wird. Beispielsweise ergibt ein Wert von 20 geteilt durch eine Größe von 5 einen WSJF-Score von 4. Mit dem WSJF-Score lässt sich jetzt das Backlog definieren: Das Backlog-Item mit dem höchsten Score steht ganz oben, alle anderen Items werden absteigend sortiert.

Das Problem: Schätzungen sind eben Schätzungen

Nun taucht aus meiner Sicht bei der Berechnung des WSJF-Score ein Problem auf: Es wird so getan, als wären die Schätzungen genaue Werte. Das sind sie aber nicht. Schätzungen sind Vermutungen, die auf unvollständigen und verzerrten Informationen basieren. Wenn Schätzungen genaue Angaben wären, wären sie keine Schätzungen mehr.

Mit dieser Erkenntnis im Hinterkopf sollten wir in die Gleichung daher sogenannte „Abweichungsterme“ integrieren. Ein Abweichungsterm drückt die Abweichung vom tatsächlichen Wert aus, zum Beispiel: Ist ein Wert tatsächlich 8 und wird aber auf 13 geschätzt, dann ist der Abweichungsterm 5. Um es einfach zu halten, ignoriere ich die Verzerrung, die durch die schätzende Person entsteht – das heißt, ich nehme an, dass sich diese Verzerrung auf alle Elemente gleichermaßen auswirkt. Das ist natürlich eine Trivialisierung, die ich aber eingehen kann, da sie die Grundaussage dieses Beitrages nicht verändert.

Mit den Abweichungstermen erhalte ich:

  • Wert = „tatsächlicher“ Wert + Abweichung auf den Wert
  • Größe = „tatsächliche“ Größe + Abweichung bei der Größe

Das Wort „tatsächlich“ habe ich nicht ohne Grund in Anführungszeichen gesetzt: Menschen sind ganz einfach nicht in der Lage, den tatsächlichen Wert und die tatsächliche Größe zu bestimmen – die Bestimmungsversuche sind immer von ganz viel Subjektivität durchzogen.

Deshalb ist es so wichtig, Abweichungsterme in die Gleichung aufzunehmen: Wenn ich zwei Zahlen dividiere, die beide eine Abweichung enthalten, pflanzt sich die Abweichung fort. Die Fortpflanzung verstärkt sich durch die Fibonacci-Skala sogar noch, weil zwei benachbarte Elemente in dieser Skala immer mindestens 60 % voneinander entfernt sind.

Was passiert da also? Wenn ich den Wert zu hoch schätze, dann hat ein Backlog-Item einen um mindestens 60 % höheren Wert als geschätzt – und das selbst dann, wenn der Unterschied zwischen „Tatsache“ und Annahme nur geringfügig ist. Wenn ich den Wert zu niedrig ansetze, hat ein Backlog-Item einen um mindestens 30 % niedrigeren Wert als geschätzt.

Dazu ein konkretes Beispiel.

  • Wenn ich ein Element auf 8 schätze und sich aber – wie auch immer – herausstellt, dass es „tatsächlich“ eine 5 ist, habe ich es um 60 % überschätzt.
  • Wenn sich herausstellt, dass es „tatsächlich“ eine 13 ist, habe ich es um 38,5 % unterschätzt.

Wenn ich mit diesen Schätzungen nicht 100-prozentig genau bin, kann ich also um den Faktor 2,5 daneben liegen! Das Gleiche gilt für die Größe, was sich leicht nachvollziehen lässt.

Das eigentliche Problem tritt nun auf, wenn ich „Wert“ und „Größe“ dividiere, was ich ja machen muss, um den WSJF-Score zu berechnen. Dazu wieder ein konkretes Beispiel:

Backlog-Item „xyz“ wurde als Wert 5 geschätzt, aber es war eigentlich ein Wert 2. Die Größe wurde als 5 geschätzt, aber es war eigentlich eine Größe 13. Damit ist die Abweichung im Wert gleich 3 und in der Größe -8.

  • Der geschätzte WSJF-Score = (2 + 3)/(13 - 8) = 1
  • Der „tatsächliche“ WSJF-Score = 2/13 = 0,15

Das ist schon ein beträchtlicher Unterschied zwischen 1 und 0,15, oder? Dieser Unterschied ist bereits bei nur kleinen Abweichungen in der Schätzung entstanden. Die Sache ist: Wir wissen nicht, wo wir in den Schätzungen zu sehr abweichen, denn sonst würden wir ja erst gar nicht abweichen. Uns passieren auch unterschiedliche Abweichungen, sonst würden sie die Skala überhaupt nicht beeinflussen. Abweichungen im Schätzen sind eben Abweichungen – sie geschehen zufällig.

WSJF passfähig einsetzen

WSJF können Sie nur dann passfähig einsetzen, wenn Sie die beschriebenen Wirkungsmechanismen kennen und in Ihre Handlungen bewusst einfließen lassen. Nehmen Sie die Zahlen nicht zu ernst und glauben Sie nicht, dass diese genau sind und die Realität gut genug abbilden, nur weil eine Entscheidung auf Zahlenbasis getroffen wird.

Ich persönlich nutze den WSJF-Score als Impuls, um ein Gespräch zu beginnen: Was sollte in der Umsetzung Priorität haben und was nicht? Die Diskussion darüber, wo der Wert entsteht und worin der Wert besteht, hat einen viel größeren Nutzen als alles, was man direkt aus einem WSJF-Score ablesen könnte.

Entfachen Sie lieber Gespräche und Diskussionen und vergessen Sie die Zahlen. Zahlen sind etwas für Maschinen.

PS: Zum Titel dieses Blogbeitrages wurde ich von diesem überaus wertvollen Dialog in brand eins mit dem Philosophen und Informatiker Mihai Nadin inspiriert.

Agile Toolbox
Scrum
Scrum-Begriffe
Conny Dethloff
April 30, 2021

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4