RICE, WSJF oder ICE: Welches Jira-Priorisierungsverfahren passt zu dir?

Die drei Verfahren auf einen Blick

Alle drei teilen eine Grundidee: Bauchgefühl durch eine Zahl ersetzen, die Wert und Kosten berücksichtigt. Sie definieren „Wert“ und „Kosten“ aber unterschiedlich — genau das bestimmt, welches zu deinem Kontext passt.

RICE-Bewertung — Nutzerwert pro Aufwandseinheit

RICE wurde von Sean McBride bei Intercom für ein konkretes Problem entwickelt: Wachsende Produktteams konnten sich nicht auf Funktionsprioritäten einigen, weil jeder Stakeholder „wichtig“ anders einschätzte. Die Formel zwingt Teams, vier konkrete Fragen zu jedem Backlog-Eintrag zu beantworten.

Worauf RICE optimiert: Der höchstbewertete Eintrag erreicht viele Nutzer, verändert deren Nutzung deutlich, funktioniert mit hoher Sicherheit und ist schnell umzusetzen. RICE misst gelieferten Nutzerwert pro Personenmonat Arbeit.

RICE funktioniert am besten, wenn:

• Du echte Daten zur Anzahl betroffener Nutzer hast (Analysen, Support-Tickets, Forschung)
• Dein Team Funktionen nach der Breite ihrer Nutzerwirkung priorisiert
• Du Verbraucher-Software oder breit genutzte B2B-Software entwickelst
• Das Team etwa 10–50 Personen hat und einen Discovery-Prozess nutzt

RICE stößt an Grenzen, wenn: Dein Backlog von regulatorischen Fristen, Partnerzusagen oder strategischen Initiativen mit wenigen betroffenen Nutzern, aber enormer Unternehmensbedeutung bestimmt wird. Eine Compliance-Funktion für fünf Unternehmenskunden, die den Verlust eines 2-Millionen-US-Dollar-Vertrags verhindert, erhält einen niedrigen RICE-Wert — obwohl sie das nicht sollte.

WSJF-Bewertung — wirtschaftlicher Wert pro Zeiteinheit

WSJF (Weighted Shortest Job First) stammt aus dem Scaled Agile Framework (SAFe) und ordnet dort Epics und Funktionen über mehrere Agile Release Trains (ARTs). Anders als RICE fragt es nicht „Welche Funktion nützt den meisten Nutzern?“, sondern „Welche Arbeit sollten wir zuerst erledigen, um die wirtschaftlichen Kosten des Wartens zu minimieren?“.

Der Zähler sind die Verzögerungskosten (Cost of Delay) — aufgeteilt in drei Komponenten:

• Geschäftswert: Relativer Wert für Unternehmen oder Endnutzer bei sofortiger Lieferung
• Zeitkritikalität: Gibt es eine Frist, ein Marktfenster oder eine Abhängigkeit, die Verzögerung teuer macht?
• Risikoreduktion / Ermöglichung von Chancen: Senkt der Eintrag ein technisches Risiko oder ermöglicht zukünftige Arbeit?

Alle vier Dimensionen (einschließlich Umfang als Nenner) werden auf einer relativen Fibonacci-Skala bewertet — typischerweise 1, 2, 3, 5, 8, 13, 20. Du bewertest Einträge im Vergleich zueinander statt auf einer absoluten Skala. Das Team wählt einen Referenzeintrag und fragt: Ist diese Funktion doppelt so wertvoll? Halb so aufwendig? Die Bewertung erfolgt gemeinsam, häufig beim PI Planning.

WSJF funktioniert am besten, wenn:

• Dein Team SAFe mit Program Increments nutzt (PI Planning)
• Deine Arbeit Fristen hat und Verzögerungskosten konkret sind
• Mehrere Teams gemeinsame Kapazität benötigen und eine transparente Reihenfolgemethode brauchen
• Du auf Initiative- oder Epic-Ebene statt bei einzelnen User Stories priorisierst

WSJF stößt an Grenzen, wenn: Dein Backlog von Nutzerforschung statt geschäftlichen Fristen bestimmt wird. Bei den meisten Funktionen liegt Zeitkritikalität dann bei 1 oder 2 — die Rangfolge wird flach, und WSJF wirkt wie eine komplizierte Form von „Geschäftswert zuerst“.

Eine detaillierte Jira-Einrichtungsanleitung mit Fibonacci-Vorlagen und PI-Planning-Konfiguration findest du hier: WSJF in Jira: SAFe-Priorisierung ohne Tabellenkalkulation.

ICE-Bewertung — schnell zu einer ersten Rangfolge

Sean Ellis, Gründer von GrowthHackers, machte ICE bekannt, um große Mengen von Experimentideen in Growth-Teams schnell einzuordnen. Die Einfachheit ist bewusst — keine Schätzungen pro Nutzer, kein Fibonacci-Workshop, keine Discovery-Daten nötig. Bewerte Wirkung, Sicherheit und Einfachheit jeweils mit 1–10, multipliziere sie und bilde die Rangfolge.

Worauf ICE optimiert: Ideen mit hoher Wirkung, hoher Sicherheit und niedrigem Aufwand (= hoher Einfachheit) steigen nach oben. Es belohnt schnelle Erfolge — einfach durchführbare Experimente mit hoher Erfolgsaussicht.

ICE funktioniert am besten, wenn:

• Du viele kleine Experimente oder Hypothesen einordnen musst (mehr als zehn Ideen pro Woche)
• Discovery-Zeit knapp ist — du brauchst eine Bewertung in zwei Minuten statt zwei Tagen
• Dein Team klein und in einer frühen Phase ist (unter zehn Personen)
• Es um Wachstumsschleifen, A/B-Tests, Marketingexperimente oder MVP-Funktionsentscheidungen geht

Die Abwägung bei ICE: Ohne Reichweitendimension unterscheidet ICE nicht zwischen einer Idee für fünf Nutzer und einer für 5.000. Bei Backlogs mit stark unterschiedlicher Nutzerzahl ist das ein wesentlicher blinder Fleck. Teams beginnen häufig mit ICE und wechseln zu RICE, sobald das Produkt genug Daten für verlässliche Reichweitenschätzungen liefert.

Direkter Vergleich

Entscheidungsbaum: Dein Verfahren wählen

Beantworte die Fragen der Reihe nach. Stoppe beim ersten Treffer.

Kannst du mehr als eines nutzen?

Ja — gut geführte Produktorganisationen tun das häufig. Eine übliche Aufteilung: Nutze RICE auf Funktionsebene (einzelne Backlog-Einträge, Schätzung von User Stories) und WSJF auf Initiativebene (Quartalsplanung, Epic-Reihenfolge über Teams hinweg). ICE kann als schneller Vorfilter dienen — Ideen unter einer Mindestgrenze aussortieren, bevor du Zeit in vollständige RICE-Bewertung investierst.

In Jira bestehen alle drei Verfahren als separate benutzerdefinierte Felder nebeneinander. Ein Vorgang kann gleichzeitig RICE 240, WSJF 6,5 und ICE 350 haben. Im Priority-Scoring-Dashboard wechselst du die Rangfolgeansicht mit einem Klick — hilfreich, wenn Produktteam (zuerst RICE) und Entwicklungsleitung (zuerst WSJF) dasselbe Backlog prüfen.

Zwischen RICE-, WSJF- und ICE-Rangfolgen im Priority-Scoring-Dashboard wechseln — dasselbe Backlog aus unterschiedlichen Perspektiven

Von Grund auf beginnen: Eine praktische erste Woche

Wenn dein Team noch nie strukturiert priorisiert hat, ist eine überkomplizierte Einrichtung das größte Risiko. Dieser einfache Ablauf funktioniert für die meisten Teams:

1. Tag 1: Installiere Priority Scoring for Jira. Ergänze ein Verfahrensfeld (ICE bei kleinen, RICE bei mittelgroßen Teams) in der Maske deines aktivsten Projekts.
2. Tag 2–3: Bewerte die wichtigsten 20 Backlog-Vorgänge. Strebe Einheitlichkeit statt Perfektion an. Nutze für alle 20 dieselben Definitionen von Aufwand und Reichweite.
3. Tag 4: Nutze die Rangfolgeansicht in der nächsten Sprint-Planung. Achte darauf, wo die Bewertung deinem Gefühl entspricht und wo nicht. Abweichungen sind besonders wertvoll — sie erzwingen ein Gespräch.
4. Ab Woche 2: Stimme die Schwellen ab. Bewerte neue Vorgänge bei ihrem Eingang. Ergänze bei Nutzen ein zweites Verfahren zur Gegenprüfung.

Häufig gestellte Fragen