Backlog priorisieren: RICE, MoSCoW und die Value-Effort-Matrix

Ein Backlog zu priorisieren bedeutet, die Reihenfolge der Arbeit nach einem nachvollziehbaren Verfahren festzulegen statt nach Bauchgefühl. Die Kurzantwort für Eilige: Kleine Teams fahren mit der Value-Effort-Matrix am besten, RICE lohnt sich bei vielen konkurrierenden Feature-Ideen, und MoSCoW spielt seine Stärke aus, wenn eine Deadline oder ein Release den Rahmen setzt. Warum das so ist – und wie die Verfahren konkret funktionieren – zeigt dieser Beitrag an einem durchgehenden Beispiel.

Wichtiger als die Wahl der Methode ist übrigens, überhaupt eine zu haben. Ohne Verfahren entscheidet in jeder Diskussion die lauteste Stimme, der jüngste Kundenanruf oder die Idee mit dem besten Pitch. Ein Verfahren zwingt alle Argumente in dieselbe Form – erst dadurch werden sie vergleichbar.

Vor der Methode: das Backlog aufräumen

Kein Verfahren rettet ein Backlog mit 200 ungepflegten Einträgen. Vor dem Priorisieren steht ein ehrlicher Durchgang: Duplikate zusammenführen, Erledigtes schließen, Uraltes ohne schlechtes Gewissen archivieren. Was seit einem Jahr unangetastet liegt und niemandem gefehlt hat, braucht keinen Score – es braucht ein Archiv. Übrig bleiben sollte eine Liste, die klein genug ist, um sie in einer Sitzung durchzugehen. Woher gute Einträge kommen, beschreibt der Beitrag über das Bündeln von Produktfeedback.

MoSCoW: grob, schnell, deadline-tauglich

MoSCoW stammt aus der agilen Projektmethodik und sortiert Einträge in vier Gruppen: Must have (ohne das scheitert das Vorhaben), Should have (wichtig, aber notfalls verschiebbar), Could have (schön, wenn Zeit bleibt) und Won't have (diesmal bewusst nicht). Die Methode beantwortet keine Reihenfolge-Fragen innerhalb einer Gruppe – ihre Stärke ist die harte Trennlinie zwischen „nötig“ und „gewünscht“.

Beispiel: Relaunch mit festem Termin

Eine Agentur baut einen Shop-Relaunch mit Livegang am 30. September. Must: Checkout funktioniert, Produktdaten migriert, Weiterleitungen stehen. Should: verbesserte Suche, neue Filialseiten. Could: Animationen, Dark Mode. Won't (diesmal): Mehrsprachigkeit. Der Gewinn liegt im letzten Punkt: Won't ist keine Absage, sondern eine dokumentierte Entscheidung – sie beendet die Diskussion, die sonst alle zwei Wochen neu aufflammt.

Die typische Falle

In der Praxis will jeder Beteiligte seine Punkte in „Must“ sehen, und nach zwei Runden ist die Gruppe so groß wie das halbe Backlog. Als Gegenmittel hat sich eine Faustregel bewährt: Die Must-Gruppe darf höchstens rund 60 Prozent der verfügbaren Kapazität füllen. Der Rest bleibt Puffer für Should und Ungeplantes. Die Zahl ist kein Naturgesetz, aber eine wirksame Verhandlungsgrenze.

RICE: rechnen, wenn viele Ideen konkurrieren

RICE wurde beim Software-Anbieter Intercom entwickelt und bewertet jeden Eintrag mit vier Faktoren: Reach (wie viele Nutzer betrifft es in einem Zeitraum), Impact (wie stark wirkt es pro Person – üblich ist eine Skala von 0,25 bis 3), Confidence (wie sicher sind die Schätzungen, in Prozent) und Effort (Aufwand, etwa in Personenwochen). Der Score ergibt sich aus Reach mal Impact mal Confidence, geteilt durch Effort.

Das Rechenbeispiel

Ein kleines SaaS-Team vergleicht drei Kandidaten aus seinem Backlog:

• CSV-Export: 120 betroffene Nutzer pro Quartal (aus den gebündelten Anfragen), Impact 2, Confidence 80 %, Aufwand 2 Wochen → (120 × 2 × 0,8) / 2 = Score 96
• Onboarding-Tour: 400 Neuregistrierungen pro Quartal, Impact 1, Confidence 50 % (Wirkung ungetestet), Aufwand 3 Wochen → (400 × 1 × 0,5) / 3 = Score 67
• Dark Mode: 60 Nutzer laut Umfrage, Impact 0,5, Confidence 80 %, Aufwand 3 Wochen → (60 × 0,5 × 0,8) / 3 = Score 8

Das Ergebnis überrascht: Die Onboarding-Tour erreicht dreimal mehr Menschen als der Export, verliert aber trotzdem – weil die Wirkung unsicher ist und der Aufwand höher. Genau das ist der Wert von RICE: Nicht die Zahl am Ende, sondern der Zwang, Reichweite, Wirkung und Unsicherheit einzeln zu begründen. Ein niedriger Confidence-Wert ist dabei ein Arbeitsauftrag – erst validieren, dann bauen.

Die Grenzen

RICE erzeugt Scheingenauigkeit: Ein Score von 96 gegen 67 sieht nach Mathematik aus, basiert aber auf Schätzungen. Wer die Eingangswerte nicht begründen kann, rechnet nur sein Bauchgefühl in Zahlen um. Und für ein Backlog mit fünfzehn Einträgen ist der Aufwand schlicht zu hoch – dafür gibt es die Matrix.

Die Value-Effort-Matrix: der schnellste Einstieg

Zwei Achsen, vier Quadranten: Wirkung (hoch/niedrig) gegen Aufwand (klein/groß). Jeder Eintrag landet in einem der vier Felder – Zuerst machen (hohe Wirkung, kleiner Aufwand), Einplanen (hohe Wirkung, großer Aufwand), Nebenbei (kleine Wirkung, kleiner Aufwand) und Bewusst streichen (kleine Wirkung, großer Aufwand).

Der Ablauf im Team dauert eine halbe Stunde: Jede Person ordnet die Einträge zunächst still für sich ein, dann werden nur die Abweichungen diskutiert. Wenn drei Leute eine Aufgabe in „Zuerst machen“ sehen und eine in „Bewusst streichen“, liegt dort ein verstecktes Missverständnis – und genau dieses Gespräch ist wertvoller als jeder Score. Aufwand schätzt dabei, wer die Arbeit später macht, nicht wer sie sich wünscht.

Welche Methode wann?

• Unter etwa 20 Einträgen und ein kleines Team: Value-Effort-Matrix – schnell, gemeinsam, ausreichend.
• Fester Termin oder Release-Zuschnitt: MoSCoW – die Must-Grenze strukturiert die Verhandlung.
• Viele ähnliche Feature-Ideen und belastbare Nutzerzahlen: RICE – der Score macht Unterschiede sichtbar.
• In Kombination: Matrix für den Quartalsblick, MoSCoW je Release – RICE nur für die strittigen Fälle.

Einen breiteren Überblick über weitere Frameworks wie Kano oder WSJF bietet der deutschsprachige Priorisierungs-Leitfaden von Atlassian – für die meisten kleinen Teams sind die drei hier beschriebenen aber mehr als genug.

Vom Score zur Reihenfolge im Alltag

Eine Priorisierung, die in einer Tabelle liegt, ist nach zwei Wochen vergessen. Das Ergebnis muss dorthin, wo gearbeitet wird: als Priorität am Vorgang und als Reihenfolge im Board. In IssuePilot setzt du die Priorität direkt an der Aufgabe, sortierst die Liste danach und siehst beim Planen zusätzlich, welche Aufgaben andere blockieren – denn eine hohe Priorität nützt wenig, wenn die Aufgabe auf etwas anderes wartet. Die großen, geclusterten Themen wandern von dort auf die Roadmap.

cockpit.issuepilot.app/issues

Häufige Fehler

• Einmal scoren, nie aktualisieren: Prioritäten altern – ein kurzer Durchgang pro Quartal hält sie ehrlich.
• Alles ist Must: Ohne Obergrenze verliert die Einteilung ihren Sinn.
• Aufwand ohne die Umsetzenden schätzen: Die Zahl stimmt dann verlässlich nicht.
• Priorisieren statt aufräumen: 200 Einträge zu scoren ist Beschäftigung, kein Fortschritt.
• Die Methode wechseln, statt zu entscheiden: Wenn das Ergebnis nicht gefällt, liegt es selten am Framework.