Backlog priorisieren: WSJF, MoSCoW und RICE mit Rechenbeispiel

Warum ist die Reihenfolge im Backlog so wichtig?

Ein Backlog enthält fast immer mehr, als ein Team in absehbarer Zeit umsetzen kann. Die Reihenfolge entscheidet deshalb, welcher Wert wann entsteht und was möglicherweise nie umgesetzt wird. Der Scrum Guide beschreibt den Product Backlog als geordnete, sich entwickelnde Liste dessen, was das Produkt verbessern soll, und weist die Ordnung dem Product Owner zu, der für die Maximierung des Produktwerts verantwortlich ist ^[1]. Wer den Backlog ändern möchte, muss den Product Owner überzeugen.

In der Praxis ist Priorisierung eine der schwierigsten Aufgaben. Stakeholder haben unterschiedliche Interessen, jede Abteilung hält ihre Wünsche für dringend, und laute Stimmen setzen sich leicht durch. Priorisierungsmethoden helfen, die Entscheidung nachvollziehbar zu machen, Annahmen offenzulegen und Diskussionen auf Kriterien statt auf Durchsetzungskraft zu stützen.

Wie funktioniert WSJF?

Weighted Shortest Job First stammt aus der Produktentwicklungsökonomie von Don Reinertsen und wird im Scaled Agile Framework genutzt. SAFe beschreibt WSJF als Priorisierungsmodell, das Arbeit so ordnet, dass der grösste wirtschaftliche Nutzen entsteht, und schätzt es als relative Kosten der Verzögerung geteilt durch die relative Dauer, wobei die Grösse als Näherung für die Dauer dient ^[2]. Die Kosten der Verzögerung setzen sich in SAFe aus drei Komponenten zusammen: Nutzen für Anwender und Geschäft, Zeitkritikalität sowie Risikoreduktion beziehungsweise Ermöglichung von Chancen.

Geschätzt wird relativ, meist mit einer modifizierten Fibonacci-Reihe wie 1, 2, 3, 5, 8, 13, 20. Für jede Komponente erhält der kleinste Eintrag den Wert 1, die anderen werden im Verhältnis dazu bewertet. Die Summe der drei Komponenten ergibt die Kosten der Verzögerung, geteilt durch die Grösse ergibt sich der WSJF-Wert. Einträge mit hohem Wert werden zuerst umgesetzt: Sie bringen viel Nutzen pro Aufwand oder sind besonders dringend.

Die Reihenfolge nach WSJF lautet D, C, A, E, B. Auffällig ist, dass das Kundenportal mit dem höchsten Nutzen zuletzt kommt, weil es sehr gross ist. Das ist ein typisches Ergebnis von WSJF und oft ein Anlass, grosse Einträge zu zerlegen: Ein erster, kleiner Teil des Portals mit hohem Nutzen hätte einen deutlich besseren WSJF-Wert. Das Sicherheitsupdate steht vorne, weil es klein ist und ein hohes Risiko reduziert.

Wie wendet man MoSCoW richtig an?

MoSCoW stammt aus dem DSDM-Rahmenwerk des Agile Business Consortium und ordnet Anforderungen vier Kategorien zu: Must Have, Should Have, Could Have und Won't Have this time. Die Must Haves bilden das minimale nutzbare Ergebnis, das garantiert geliefert wird. DSDM empfiehlt, den Aufwand für Must Haves typischerweise auf höchstens 60 Prozent zu begrenzen und einen Puffer an Could Haves von etwa 20 Prozent des Aufwands vorzusehen ^[3]. Entscheidend ist, dass sich die Anteile auf den Aufwand beziehen, nicht auf die Anzahl der Einträge.

Die grösste Gefahr bei MoSCoW ist die Inflation der Must Haves. Wenn alle Stakeholder ihre Wünsche als Must einstufen, verliert die Methode ihren Sinn. Die Begrenzung des Must-Aufwands wirkt hier als Schutz: Überschreiten die Must Haves die Grenze, müssen Einträge herabgestuft werden. Die Kategorie Won't Have ist ebenso wichtig, weil sie Erwartungen klärt und verhindert, dass Wünsche unbemerkt im Hintergrund weiter existieren. Eine Übersicht bietet auch das Glossar unter MoSCoW-Priorisierung.

Was misst der RICE-Score?

RICE wurde in der Produktentwicklung bei Intercom bekannt und bewertet Einträge nach vier Faktoren: Reach, also wie viele Personen in einem Zeitraum betroffen sind; Impact, also wie stark die Wirkung pro Person ist, etwa auf einer Skala von 0,25 bis 3; Confidence, also wie sicher die Schätzungen sind, als Faktor zwischen 0 und 1; und Effort, also der Aufwand in Personenmonaten. Der Score ergibt sich aus Reach mal Impact mal Confidence, geteilt durch Effort.

Die schnellere Suche gewinnt, obwohl ihr Impact pro Person gering ist, weil sie sehr viele Personen erreicht und die Schätzung sicher ist. Die Integration mit der Buchhaltung hat die grösste Wirkung pro Person, aber geringe Reichweite und unsichere Schätzung. RICE eignet sich besonders für Produkte mit vielen Nutzenden und messbarer Reichweite; für interne Projekte mit wenigen Betroffenen ist WSJF oder MoSCoW oft passender.

Welche Methode passt wann?

Viele Teams kombinieren Methoden: MoSCoW für die Frage, was in ein Release gehört, WSJF für die Reihenfolge innerhalb der Must und Should Haves. Wichtig ist, eine Methode konsequent anzuwenden und die Bewertungen transparent zu machen, damit Stakeholder nachvollziehen können, warum ihr Wunsch an einer bestimmten Stelle steht.

So führen Sie einen Priorisierungs-Workshop durch

1. 1Einträge vorbereiten: verständlich beschrieben, ungefähr gleich granular, grosse Einträge vorher zerlegen.
2. 2Kriterien klären: Was bedeutet Nutzen, Dringlichkeit, Risiko in diesem Produkt?
3. 3Relativ schätzen: den kleinsten Eintrag je Kriterium als Referenz festlegen, dann vergleichen.
4. 4Ergebnis berechnen und sortieren.
5. 5Plausibilität prüfen: Fühlt sich die Reihenfolge richtig an? Wenn nicht, welche Annahme stimmt nicht?
6. 6Entscheid des Product Owners festhalten und an Stakeholder kommunizieren.

Die Plausibilitätsprüfung ist der wichtigste Schritt. Ein Ergebnis, das niemand für richtig hält, deutet auf falsche Schätzungen oder fehlende Kriterien hin, etwa rechtliche Pflichten, die in keiner Formel stehen. Methoden sind Werkzeuge für eine bessere Diskussion, keine Automaten für Entscheide. Wie Einträge so formuliert werden, dass sie gut verglichen werden können, zeigt der Beitrag User Stories schreiben; wie ihre Grösse geschätzt wird, der Beitrag Agile Schätzverfahren.

Wie gehen Sie mit Druck von Stakeholdern um?

Priorisierung erzeugt immer Enttäuschung, weil nicht alle Wünsche gleichzeitig umgesetzt werden können. Hilfreich ist ein offener Prozess: Stakeholder kennen die Kriterien, sehen die Bewertung ihrer Wünsche und wissen, wann und wie sie neue Informationen einbringen können. Ein regelmässiger Termin, etwa einmal pro Sprint oder Monat, in dem der Product Owner die Reihenfolge mit den wichtigsten Stakeholdern bespricht, verhindert, dass Wünsche über informelle Kanäle direkt beim Team landen.

Entscheidend ist, dass der Product Owner tatsächlich entscheiden darf. Der Scrum Guide hält fest, dass die gesamte Organisation seine Entscheidungen respektieren muss, damit er erfolgreich sein kann. Wird die Reihenfolge regelmässig von Führungskräften übersteuert, verliert der Backlog seine Funktion, und das Team arbeitet faktisch nach Zuruf. In solchen Situationen hilft es, die Kosten von Unterbrechungen sichtbar zu machen, etwa über die verlorene Zeit und die verschobenen Ziele.

Transparenz über die Kriterien ist deshalb wichtiger als die Wahl der Methode selbst.

Priorisierung in Scrum, SAFe und klassischen Projekten

Scrum schreibt keine Priorisierungsmethode vor, legt aber die Verantwortung eindeutig beim Product Owner fest. SAFe nutzt WSJF auf mehreren Ebenen, von Features bis zu Epics im Portfolio. In klassischen Projekten entspricht die Priorisierung der Festlegung von Muss- und Kann-Anforderungen im Lastenheft; MoSCoW wird dort ebenfalls häufig verwendet, etwa im Scope-Management, siehe Scope-Management und Änderungskontrolle. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.