WSJF, Cost of Delay und warum der lauteste Stakeholder die Backlog-Debatte immer gewinnt

Vor ein paar Monaten saß ich in einem PI-Planning, in dem ein zwölfköpfiges Team vierzig Minuten darüber debattierte, ob ein "Produktalternativen anzeigen"-Button wichtiger sei als ein "Notify me"-Button für ausverkaufte Artikel. Beide PMs hatten Folien. Beide hatten Daten. Beide waren überzeugt. Die Diskussion endete so, wie solche Diskussionen immer enden; die lauteste Person im Raum gewann, und der Rest kehrte mit leisem Groll zu seinem Laptop zurück.

Dieses Meeting ist der Grund, warum ich unseren WSJF-Rechner neu gebaut habe. Nicht weil die Welt noch ein weiteres Backlog-Priorisierungstool braucht, sondern weil ich es leid war, kluge Teams ein ganzes Quartal mit Bauchgefühl-Debatten verbrennen zu sehen, obwohl die Mathematik seit den 80ern existiert.

Der Trick, den dir niemand über Priorisierung verrät

Die meisten denken, Priorisierung heißt, das Wertvollste zu wählen. Tut sie nicht. Sie heißt, das zu wählen, wo Wert geteilt durch Größe am höchsten ist. Das klingt pedantisch, bis du merkst, dass es der Unterschied ist zwischen acht kleinen Siegen pro Quartal und einer einzigen schwerfälligen "strategischen Initiative", die eigentlich keiner wollte.

Das ist die gesamte These hinter Weighted Shortest Job First. Du bewertest jedes Backlog-Item in zwei Dingen; wie teuer es ist, es zu verzögern, und wie groß der Job ist. Dann teilst du. Der höchste Score gewinnt. Fertig. Keine Story-Point-Debatten montags um 9 Uhr, kein "ist die Login-Seite eine 3 oder eine 5", kein Tun, als wäre dein Bauchgefühl eine Methodik.

WSJF = Cost of Delay / Job Size

Don Reinertsen hat das in The Principles of Product Development Flow populär gemacht, das ich das beste jemals geschriebene Agile-Buch nennen würde, wenn die Formulierung "Agile-Buch" nicht die meisten Ingenieure dazu bringen würde, zum nächsten Fenster zu schauen. Es ist eigentlich ein Buch über Warteschlangentheorie, verkleidet als Management-Buch, und deshalb ist es so gut.

Cost of Delay sind drei Dinge, nicht eins

Hier gehen die meisten WSJF-Tabellen in die Irre. Cost of Delay ist keine einzelne Zahl. Es ist die Summe aus drei sehr unterschiedlichen Fragen:

• Geschäftswert. Wenn wir das morgen ausliefern würden, wie sehr würde das Nutzer oder das Business interessieren? Umsatz, Retention, ein konkretes OKR. Konkret, wenn möglich, relativ, wenn nicht.
• Zeitkritikalität. Verfällt der Wert mit der Zeit? Ein Black-Friday-Feature im Dezember ist ungefähr nichts wert. Eine verpasste Compliance-Frist ist weniger als nichts wert.
• Risikoreduktion / Opportunity Enabling. Schaltet das etwas anderes frei oder nimmt es Unsicherheit heraus? Langweilige Infrastrukturarbeit lebt hier und wird normalerweise genau hier beerdigt.

Addiere diese drei. Das ist Cost of Delay. Teile durch Job Size. Das ist WSJF. Der Grund, warum das funktioniert, ist nicht, dass die Zahlen genau sind; es ist, dass das Gespräch genau wird. Du kannst nicht mehr so tun, als wäre ein Risk-Reduction-Spike ein Umsatz-Feature. Jedes Item muss sich auf drei Achsen rechtfertigen, bevor es einen Score bekommt.

Warum relative Größen Stunden jedes Mal schlagen

Die andere Falle ist, wie du Größen schätzt. Leute wollen in Tagen schätzen. Tu das nicht. Menschen sind furchtbar darin, Dauer zu schätzen, und wir haben jahrzehntelange Verhaltensforschung, die das belegt; Parkinsons Gesetz allein sollte dich abschrecken. Was Menschen passabel können, ist, zwei Dinge zu vergleichen und zu sagen "das ist größer".

Also bewerte in Fibonacci (1, 2, 3, 5, 8, 13, 20) oder T-Shirt-Größen (XS, S, M, L, XL, XXL). Die Sprünge zählen; ein Sprung von 5 auf 8 erzwingt ein Gespräch, das "4 Tage vs 5 Tage" nicht erzwingt. Unser Tool unterstützt beide, weil Teams darüber streiten, und der Streit lohnt sich nicht. Entscheide dich für eins. Weiter.

Was das Tool tatsächlich tut

Der WSJF-Rechner läuft in deinem Browser. Nichts verlässt deinen Rechner. Ich bin da besonders bei Product-Management-Tools zwanghaft; deine Roadmap ist genau die Art Daten, die du nicht auf dem Server von jemand anderem haben willst.

Das haben wir eingebaut, nachdem wir Teams damit arbeiten gesehen haben:

1. Templates für typische Domänen. E-Commerce, SaaS, interne Plattform, regulierte Branche. Starte von etwas, das bereits Sinn ergibt.
2. What-if-Analyse. Blase die Größe des Top-Items um 25% auf. Dreht sich die Reihenfolge? Wenn ja, ist deine Top-Priorität fragil; neu schätzen, bevor du dich committest.
3. Robustheitsindikator. Liegen die Top-drei-WSJF-Scores innerhalb von 10%, behandle sie als gleich und lass die Teamkapazität entscheiden. Das Tool zeigt das in Echtzeit, damit du aufhörst, so zu tun, als sei 4,20 deutlich größer als 4,10.
4. Teilbare Links. Kopiere eine URL, klebe sie in die PI-Planning-Notizen, alle laden denselben Backlog-Stand. Keine Jira-Exporte, keine CSVs, die durch Slack geistern.
5. CSV- und PDF-Export. Weil manche Stakeholder nur einer PDF trauen.

Wann WSJF die falsche Antwort ist

Ich erspare dir einen Fehler, den ich gemacht habe. WSJF ist kein universelles Priorisierungs-Framework. Es ist das richtige Werkzeug, wenn:

• Du 15 oder mehr grob vergleichbare Backlog-Items hast.
• Dein Team in kurzen Zyklen kontinuierlich liefert.
• Cost of Delay zwischen Items tatsächlich variiert (manches ist zeitkritisch, manches nicht).

Es ist das falsche Werkzeug, wenn:

• Du eine einzelne strategische Wette und drei Support-Tickets hast. Mach die Wette.
• Alles gleich dringend ist. Dann ist nichts dringend, und du hast ein Managementproblem, kein Priorisierungsproblem.
• Du zwischen zwei Produkten entscheiden willst. Das ist eine Kano- oder Portfolio-Frage.

Für binäre Rein/Raus-Entscheidungen nimm MoSCoW oder die Eisenhower-Matrix. Für Consumer-Feature-Ranking mit einer einfacheren Formel ist RICE freundlicher. Ich habe Versionen von allen drei gebaut; jedes löst eine leicht andere Problemform.

Das Meeting-Ritual, das tatsächlich funktioniert

WSJF bricht, wenn es zum Ritual wird. Der Rechner macht die Mathematik; die Menschen müssen reden. Das ist die Schleife, die bei mir funktioniert hat:

1. Bewertet Cost of Delay zuerst, gemeinsam. Nutzt Planning Poker, um Uneinigkeit sichtbar zu machen. Wenn zwei Leute 3 und 13 gegeben haben, ist das interessant; nachhaken.
2. Bewertet Job Size als Letztes. Wenn ihr die Größe zuerst kennt, verankert sie die Wertschätzung. Menschen sind so faul.
3. Lies die Top drei laut vor. Wenn jemand zuckt, neu bewerten.
4. Einfrieren und liefern. Nicht mitten im Sprint nachbewerten. Der Sinn ist ja, dass gestern und heute unterschiedlich gefühlt werden, aber die Mathematik sich nicht bewegt hat.

Für Commitments mit längerem Horizont kombiniere WSJF mit probabilistischem Forecasting. Ich habe ein ganzes Stück über Monte-Carlo-Forecasting für agile Delivery geschrieben, das gut dazu passt; das eine Tool sagt dir was als Nächstes, das andere wann du realistisch fertig bist.

Was mich überrascht hat

Als ich den Rechner veröffentlicht habe, habe ich erwartet, dass Ingenieure ihn nutzen. Es hat sich herausgestellt, dass Product Manager die intensivsten Nutzer sind, und was sie am meisten lieben, ist nicht der Score. Es ist der Audit Trail. Jedes Ranking zeigt die drei Sub-Scores; wenn ein Stakeholder fragt "warum ist mein Feature nicht oben?", zeigt der PM auf eine Zahl und sagt "weil deine Zeitkritikalität S und deine Job Size XL ist". Das Gespräch endet in einer Minute, nicht in einer Woche.

Das ist der eigentliche Sinn jedes Priorisierungstools. Urteilsvermögen nicht ersetzen. Urteilsvermögen sichtbar genug machen, dass die lauteste Person im Raum den Rest nicht mehr überschreiben kann.

Probier es hier: kitmul.com/de/agile-project-management/wsjf-calculator. Es ist kostenlos, es läuft im Browser, und dein Backlog bleibt deins.