Eine definierte Work Queue oder Backlog mit Items in vergleichbarer Größenordnung (Features, Epics, PIs) liegt vor, idealerweise mit Beschreibung des Geschäftsnutzens.
WSJF
Vorbedingung
Was vorher fertig sein muss
Team und Stakeholder haben ein gemeinsames Verständnis, was Cost of Delay bedeutet (Business Value über Zeit, Time Criticality, Risk Reduction / Opportunity Enablement).
Vorbereitung
Was vor Start vorliegen muss
Tabelle mit Spalten Item, Business Value, Time Criticality, Risk Reduction/Opportunity Enablement, Job Size, WSJF-Score; Fibonacci-Skalen-Karten (1, 2, 3, 5, 8, 13, 20); kollaboratives Tool (Planning Poker, Notion, Sheets).
Ein Product Manager oder Product Owner als Owner; Architekt oder Tech Lead für Risk- und Size-Schätzung; 2-5 Stakeholder aus Business für Value-Schätzung; Facilitator (oft RTE oder Scrum Master).
Liste der Items mit Beschreibung; aktuelle PI- oder Quartals-Ziele; bekannte Deadlines und Compliance-Anforderungen; Abhängigkeiten zwischen Items; Erfahrungswerte zu vergleichbaren Items.
45-90 min
Tabelle aufsetzen. Fibonacci-Skala für relative Schätzung erklären (kein absoluter Wert, immer relativ zueinander). Definition pro Faktor sichtbar machen. Smallest Item als 1-Referenz pro Faktor festlegen.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welches Item liefert pro Aufwand den höchsten Cost-of-Delay-Wert und sollte als nächstes gezogen werden?
Ablauf
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Referenz-Item wählen | 10 min | Für jeden der drei CoD-Faktoren (Business Value, Time Criticality, Risk Reduction / Opportunity Enablement) und für Job Size das kleinste Item als 1-Referenz festlegen. Alle anderen werden relativ dazu geschätzt. | Ohne Referenz fehlt der Anker. Schätzungen ohne Referenz werden zu Bauchwerten und produzieren keine relative Aussage. |
2Sektion 2: Business Value relativ schätzen | 10-15 min | Pro Item: wie viel Geschäftswert (Umsatz, Kostenersparnis, Strategischer Wert) im Vergleich zum Referenz-Item? Fibonacci-Skala. Im Disagreement-Fall kurze Diskussion und Re-Vote (Planning Poker). | Value rein wirtschaftlich oder strategisch, nicht persönliche Begeisterung. Wenn Stakeholder mit 20 stimmen ohne Begründung, Fragen nach quantitativer Stütze. |
3Sektion 3: Time Criticality und RR/OE | 15-20 min | Time Criticality: wie schnell verliert der Wert an Wirkung (Fenster, Konkurrenz, Deadlines)? RR/OE: wie viel Risiko reduziert oder Opportunity ermöglicht das Item? Beide relativ zur Referenz, Fibonacci. | Time Criticality wird oft missbraucht für „mir wichtig“. Strikt: was wäre der Effekt, wenn Item 3 Monate später kommt? |
4Sektion 4: Job Size schätzen | 10-15 min | Pro Item Job Size in Fibonacci relativ zur kleinsten. Team-Vertreter aus Engineering schätzen. Größen 20+ signalisieren, dass Item gesplittet werden sollte. | Job Size beinhaltet alle Aufwände (Engineering, Design, QA, Rollout). Wenn Größe unklar, Item splitten oder Spike planen vor Aufnahme. |
5Sektion 5: Score und Reihenfolge | 10 min | Formel: WSJF = (Business Value + Time Criticality + RR/OE) / Job Size. In Tabelle sortieren. Top-Items in Pull-Reihenfolge fixieren. | WSJF gibt Reihenfolge, nicht Garantie. Schwierige Sequenzen mit Abhängigkeiten brauchen manuelle Korrektur (z. B. wenn Item A vor B technisch nötig ist). |
Artefakt
Was am Ende rauskommt
Sortierte Backlog-Tabelle mit Items, Faktoren-Werten, WSJF-Score und Rang; plus Annahmen-Log mit Begründungen für hohe Time-Criticality- oder RR/OE-Werte; plus PI-Plan oder Pull-Reihenfolge mit Berücksichtigung Abhängigkeiten.
- Excel oder Google Sheets mit Formel-Spalte
- Jira Align (SAFe-spezifisch) mit WSJF-Field
- Linear oder Notion-Tabelle mit Custom-Properties
- PlanningPoker.com oder Scrumpoker.online für relative Schätzung
- Mural- oder Miro-Tabelle für Live-Schätzung
Pro Priorisierungs-Cycle (PI, Quartal) eigene Version. Items, die über mehrere Cycles bleiben, mit Score-Historie versehen, um Verschiebungen sichtbar zu machen. Lessons Learned aus geliefertem Item: tatsächlicher Wert vs. geschätzter.
WSJF Arbeitsvorlage
Kompakte Arbeitsvorlage für WSJF mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# WSJF Arbeitsvorlage
## Ziel
Sequenziert Arbeit über Cost of Delay geteilt durch Job Size.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Ranked Backlog:
- Cost-of-Delay Assumptions:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Beispielausgabe
Konkret gefülltes Szenario
## WSJF — PI 12 Backlog (Schätzung 2026-05-18)
| Item | BV | TC | RR/OE | Job Size | WSJF |
|---|---|---|---|---|---|
| 3DS2-Compliance-Update | 13 | 20 | 8 | 5 | 8,2 |
| Apple-Pay-Integration | 8 | 5 | 3 | 8 | 2,0 |
| Multi-Tenancy für Enterprise | 20 | 3 | 13 | 20 | 1,8 |
| Performance-Refactoring Order-Service | 5 | 3 | 8 | 8 | 2,0 |
| Saved-Card-Option | 5 | 2 | 1 | 3 | 2,7 |
| Loyalty-Programm | 8 | 3 | 5 | 13 | 1,2 |
**Annahmen**:
- 3DS2 TC=20, weil Deadline 30.06. regulatorisch.
- Multi-Tenancy BV=20, weil Vertragsanbahnung Enterprise-Kunden hängt davon ab.
- Performance-Refactoring RR=8, weil aktuell P95 800ms (SLA 500ms gefährdet).
**Pull-Reihenfolge**: 3DS2 (Compliance), dann Saved-Card (Quick Win), dann Performance-Refactoring (vor Loyalty wegen Stabilitäts-Risiko). Multi-Tenancy wartet auf Vertragsklärung.Stolperfallen
Symptome erkennen, gegensteuern
Absolute statt relative Werte
Teilnehmer schätzen Business Value in EUR oder Punkten ohne Bezug zur Referenz.
Referenz-Item-Verfahren strikt anwenden. Werte sind immer „X-mal mehr als Referenz 1“. Sonst sind Werte nicht vergleichbar.
Time Criticality entwertet
Alles bekommt TC=8 oder 13, weil „dringend ist alles“.
TC nur hoch, wenn echte Deadline oder Wertabfall existiert. Wenn Item in 3 Monaten gleichen Wert hat, TC ist niedrig. Verteidigen oder runtersetzen.
Job Size mit anderen Faktoren vermischt
Job Size enthält Risiko oder Komplexität (statt nur Aufwand), Doppelzählung mit RR/OE.
Job Size = reiner Aufwand (Personenwochen oder relative Komplexität). Risiko gehört in RR/OE oder als separate Spalte.
Score als Diktat
Team folgt Score strikt, ignoriert Abhängigkeiten oder strategische Themen.
Nach Score-Berechnung Sanity-Check mit Abhängigkeiten und Strategie. Manuelle Korrektur dokumentieren, nicht ignorieren.
Items zu groß
Job Size 20+ taucht häufig auf, Items sind Epics statt schneidbarer Features.
Items mit Job Size 20+ splitten. WSJF funktioniert für Features bis Mittel-Epic, nicht für Mega-Initiativen. Sonst dominieren Mega-Items das Ranking.
Abbruchkriterien
Done-Signale, in unter einer Minute prüfbar
Run Sheet durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.