RICE-Bewertung in Jira: Die vollständige Einrichtungsanleitung (2026)

Das Problem: Jira-Prioritäten sind Meinungen

Jira liefert ein Prioritätsfeld mit Höchste, Hoch, Mittel, Niedrig und Niedrigste. In den meisten Teams sind nach einem Jahr 70 % des Backlogs „Hoch“. Nicht alles hat tatsächlich hohe Priorität. Das Feld ist subjektiv, deshalb tendieren Menschen zu höheren Werten.

Die Folge: Sprint-Planung wird zur Verhandlung. Der lauteste Stakeholder gewinnt. Entwickler wissen bei zwei wartenden „Hoch“-Vorgängen nicht, welcher als Nächstes dran ist. Produktmanager können weder dem Team noch der Führung erklären, warum eine Funktion vor einer anderen ausgeliefert wird.

RICE macht die Abwägungen ausdrücklich sichtbar. Zwei Funktionen können beide wichtig und dringend sein. RICE zwingt dich zu sagen, welche wichtiger ist, und die Begründung offenzulegen.

Die RICE-Formel erklärt

RICE wurde von Sean McBride bei Intercom entwickelt, um die Funktionspriorisierung in einem wachsenden Produktteam zu vereinheitlichen. Die Formel hat vier Faktoren:

Reichweite — wie viele Menschen profitieren?

Reichweite ist die Anzahl der Nutzer oder Kunden, die eine Funktion in einem festgelegten Zeitraum betrifft — typischerweise einem Quartal. Nutze tatsächliche Zahlen statt Prozentwerte. „500 Nutzer pro Quartal“ ist besser als „mittlere Reichweite“.

Entscheidend ist Einheitlichkeit: Alle Vorgänge im Backlog müssen dasselbe Zeitfenster verwenden. Quartals- und Jahresschätzungen zu mischen verzerrt jede Bewertung der Rangliste.

Wirkung — wie groß ist der Effekt?

Wirkung ist ein Multiplikator für den Effekt auf jeden einzelnen Nutzer. Intercom definierte eine Standardskala, damit Schätzungen über Funktionen hinweg vergleichbar bleiben:

Wirkung ist die subjektivste Dimension. Die Multiplikatorskala hilft: Sie verlangt eine Aussage wie „Doppelt so gut wie der Durchschnitt“ statt vager Labels wie „wichtig“.

Sicherheit — wie sicher bist du?

Sicherheit wird als Prozentwert ausgedrückt und beschreibt die Grundlage deiner Schätzungen. Intercoms ursprüngliche Empfehlung nannte drei Stufen: 100 % (hohe Sicherheit — Daten vorhanden), 80 % (mittel — teils Daten, teils Annahmen), 50 % (niedrig — überwiegend Annahmen). Werte unter 50 % sind gültig, signalisieren aber weiteren Klärungsbedarf vor einer verlässlichen Bewertung.

Sicherheit wirkt als Risikoabschlag. Eine Funktion mit fantastischem RICE-Wert bei 50 % Sicherheit liegt hinter einer bescheideneren Funktion bei 100 % — genau das ist gewünscht. Erhöhe die Sicherheit nicht, nur damit eine Lieblingsfunktion besser aussieht.

Aufwand — wie viel kostet es?

Aufwand ist die gesamte Zeit aller Teammitglieder für diesen Vorgang in Personenmonaten. Je zwei Wochen eines Frontend- und eines Backend-Entwicklers ergeben einen Personenmonat. Berücksichtige QA, Design und Produktmanagement — nicht nur Entwicklung.

Aufwand steht im Nenner: Hoher Aufwand senkt den Wert trotz hervorragender Reichweite und Wirkung. Das ist die zentrale RICE-Erkenntnis — es geht nicht nur um gelieferten Wert, sondern um Wert pro Arbeitseinheit.

Ein Rechenbeispiel

Bewerten wir zwei Funktionen, die um denselben Sprintplatz konkurrieren:

Funktion B liegt höher, obwohl deutlich weniger Nutzer sie möchten, weil sie pro Nutzer doppelt so viel Wirkung bei einem Viertel des Aufwands liefert und sicher funktioniert. RICE macht diese Abwägung klar sichtbar, während „Priorität: Hoch“ bei beiden sie vollständig verstecken würde.

Wann RICE passt — und wann nicht

RICE funktioniert am besten, wenn dein Team Reichweite mit echten Daten schätzen kann — Nutzeranalysen, Support-Ticket-Volumen oder Interviewzahlen. Es belohnt Funktionen, die viele Menschen betreffen, und passt deshalb zu Produktteams mit nutzerbezogener oder breit eingesetzter Software.

RICE ist weniger geeignet, wenn:

• Du SAFe oder PI Planning nutzt: Nutze WSJF (Weighted Shortest Job First) stattdessen — es modelliert Verzögerungskosten und Auftragsdauer, was besser zu SAFe-Reihenfolgeentscheidungen passt.
• Du viele kleine Ideen und wenig Discovery-Zeit hast: ICE (Wirkung, Sicherheit, Einfachheit) ist schneller auszufüllen und liefert ohne Nutzerdaten eine brauchbare Richtung.
• Deine Vorgänge große Epics sind: RICE-Werte für Epics vermischen verschiedene Aspekte und werden unzuverlässig. Teile Epics zuerst in Stories auf und bewerte dann.

Bei Unsicherheit über das passende Verfahren siehe den Vergleichsleitfaden: RICE, WSJF oder ICE — welches Jira-Verfahren passt zu dir?

RICE-Bewertung in Jira einrichten

Die folgenden Schritte nutzen Priority Scoring for Jira — eine auf Forge basierende App, die RICE, WSJF und ICE als native benutzerdefinierte Felder ergänzt. Sie läuft vollständig in Atlassians Infrastruktur („Runs on Atlassian“), sodass keine Daten deine Jira-Site verlassen.

1. 1
   Installiere Priority Scoring aus dem Atlassian Marketplace. Suche nach „Priority Scoring“ und installiere die App auf deiner Jira-Cloud-Site. Eine kostenlose Testversion mit allen Funktionen ist verfügbar.
2. 2
   Füge das RICE-Bewertungsfeld zu deiner Projektmaske hinzu. Öffne Jira-Einstellungen → Vorgänge → Masken: Finde die Maske deines Projekts und ergänze „Priority Scoring — RICE“. Ohne diesen Schritt erscheinen die Schieberegler nicht in Vorgängen.
3. 3
   Öffne einen Jira-Vorgang und setze deinen ersten RICE-Wert. Du siehst vier Schieberegler — Reach, Impact, Confidence und Effort. Ziehe jeden auf den passenden Wert. Der RICE-Wert wird unmittelbar berechnet und über den Reglern angezeigt.
4. 4
   Sieh dein priorisiertes Backlog im Priority-Scoring-Dashboard. Öffne die globale Seite von Priority Scoring. Wechsle zu RICE, wähle dein Projekt und sieh alle bewerteten Vorgänge vom höchsten zum niedrigsten Wert — mit Sprint, Fälligkeitsdatum und zuständiger Person.
5. 5
   (Optional) Konfiguriere die Bewertungsschwellen. Setze in den Einstellungen niedrige und hohe Schwellen für RICE. Unterhalb der niedrigen erscheint 🔴, oberhalb der hohen 🟢. Teams erkennen Prioritäten auf einen Blick, ohne einzelne Zahlen zu lesen.

RICE-, WSJF- und ICE-Bewertungsfelder in einem Jira-Vorgang — Schieberegler je Dimension, sofort berechneter Gesamtwert

Dein priorisiertes Backlog sehen

Bewertungen einzelner Vorgänge sind hilfreich; der eigentliche Wert liegt aber in der Rangfolge des gesamten Projekts. Das Priority-Scoring-Dashboard zeigt eine sortierbare Tabelle aller bewerteten Vorgänge — Rang, RICE-Wert mit Farbkennzeichnung, Vorgangsschlüssel, Zusammenfassung, Sprint, zuständige Person und Fälligkeit.

Sortiere absteigend und arbeite von oben. Vorgänge am unteren Ende — besonders mit 🔴 — solltest du hinterfragen: Gehören sie überhaupt ins Backlog?

Priority-Scoring-Dashboard — RICE-Rangfolge aller Backlog-Vorgänge, rechts die Backlog-Gesundheit

Weiterführend: KI-gestützte Bewertung mit Rovo

Jeden Vorgang manuell zu bewerten ist die größte Einführungshürde für RICE. Priority Scoring enthält einen Rovo-KI-Agenten , der Zusammenfassung, Beschreibung und Akzeptanzkriterien liest und Dimensionswerte mit schriftlicher Begründung vorschlägt.

Der Agent arbeitet in drei Modi, konfigurierbar in den Einstellungen:

• Vorschlagsmodus: Rovo empfiehlt Werte im Chat; du übernimmst sie manuell über Schieberegler. Ein guter Einstieg für Teams, die KI-gestützte Bewertung neu nutzen.
• Bestätigungsmodus: Rovo fragt „Soll ich diesen RICE-Wert auf PROJ-123 anwenden?“ und wartet vor dem Schreiben in Jira auf deine Freigabe.
• Automatischer Modus: Rovo übernimmt Werte direkt — Atlassians nativer Berechtigungsdialog erscheint weiterhin als Absicherung auf Plattformebene.

Öffne zum Bewerten eines Vorgangs einen Rovo-Chat und schreibe: „Schlage einen RICE-Wert für PROJ-123 vor.“ Rovo ruft den Vorgang ab, begründet die Dimensionen und liefert Vorschlagswerte. Im Bestätigungs- oder automatischen Modus kann es den Wert danach direkt ins Feld schreiben.

Massenbewertung ist im automatischen Modus verfügbar: „Bewerte alle unbewerteten Vorgänge im Projekt PROJ mit RICE.“ Rovo arbeitet die Liste bis zum konfigurierten Massenlimit durch (Standard: zehn Vorgänge pro Aufruf).

Einheitliche Bewertungen im Team sicherstellen

RICE funktioniert nur mit gemeinsamen Definitionen im Team. „1.000 Nutzer“ Reichweite ist bedeutungslos, wenn jemand monatliche Nutzer und jemand anderes alle registrierten Nutzer schätzt. Einigt euch vor dem Beginn auf drei Dinge:

• Zeitfenster für Reichweite — wähle eines (Quartale sind üblich) und vermische es nie.
• Was „Nutzer“ bedeutet — alle registrierten Nutzer? Monatlich aktive? Zahlende Kunden? Halte es schriftlich fest.
• Aufwandseinheit — Personenwochen oder Personenmonate, deine Wahl, aber bleibe dabei.

Das Bewertungsprotokoll in Priority Scoring (Settings → Score Audit Trail) erfasst, wer wann welchen Wert gesetzt hat. So erkennen Teams Ausreißer und gleichen ihre Maßstäbe über die Zeit ab.

Häufig gestellte Fragen