RICE-Scoring: Formel, Rechenbeispiel und typische Fehler

RICE-Scoring ordnet Produktideen mit einer einzigen Zahl: Reichweite mal Wirkung mal Vertrauen, geteilt durch Aufwand. Ein höherer Score bedeutet mehr erwarteten Nutzen pro Arbeitseinheit. Die Methode stammt vom Produktteam bei Intercom und ist zu einem Standardweg geworden, Feature-Requests zu vergleichen, die sich nicht per Bauchgefühl trennen lassen. Sie funktioniert am besten bei einer kurzen Liste ernsthafter Kandidaten und ist nur so gut wie die Schätzungen, die hineinfließen.

Wie lautet die RICE-Formel?

Der Score ist Reichweite × Wirkung × Vertrauen ÷ Aufwand. Reichweite, Wirkung und Vertrauen werden multipliziert, weil jede den Ertrag skaliert, und der Aufwand teilt, weil derselbe Ertrag mehr kostet, wenn er mehr Arbeit verlangt. Für die Reichweite wird ein einziges Zeitfenster gewählt, etwa ein Quartal, und für jeden Eintrag verwendet, sonst sind die Scores nicht vergleichbar.

Der ursprüngliche Artikel von Intercom definiert die Skalen aus der obigen Tabelle, und die meisten Teams behalten sie unverändert, damit Scores zwischen Personen vergleichbar bleiben.

Wie bewertet man die einzelnen RICE-Faktoren?

Die Reichweite kommt aus Daten, die ihr schon habt. Bei einem Feature-Request beginnt man mit der Zahl der verschiedenen Konten, die danach gefragt haben, und addiert eine Schätzung der Konten, die es ungefragt nutzen würden. Die Wirkung ist der ungenaueste Faktor, deshalb nimmt man die Skala mit fünf Werten und erfindet keine Dezimalstellen. Das Vertrauen ist ein Abschlag fürs Raten: 100 % nur, wenn es Nutzungsdaten oder einen getesteten Prototyp gibt, 80 % bei starken Signalen und 50 %, wenn überwiegend geraten wird. Der Aufwand ist die Zeit aller Beteiligten, Design und Tests eingeschlossen, in Personenmonaten.

Zwei Personen, die denselben Eintrag bewerten, sollten bei jedem Faktor höchstens eine Stufe auseinanderliegen. Tun sie das nicht, ist der Eintrag nicht gut genug verstanden, um ihn einzuordnen, und die Uneinigkeit ist das Ergebnis.

Wie sieht ein RICE-Beispiel aus?

Nehmen wir vier Requests aus einem erfassten Backlog, bewertet über ein Quartal.

Die erste Zeile durchgerechnet: 400 × 1 × 0,8 ÷ 1 = 320. Dark Mode erreicht dreimal so viele Menschen, aber jeder von ihnen gewinnt wenig, deshalb landet er knapp unter dem Export. Die Slack-Integration hat eine gute Wirkungsnote, die das Vertrauen halbiert, und das zeigt, dass der nächste Schritt Recherche ist und nicht Bauen.

Single Sign-on steht ganz hinten, und das verdient einen zweiten Blick. Sechzig Konten sind eine kleine Reichweite, aber wenn es die größeren Konten sind und mehrere Verlängerungen vom Feature abhängen, fehlt im Score etwas, das die Methode nicht sehen kann.

Was sind die häufigsten RICE-Fehler?

Der erste ist falsche Präzision. Eine Reichweite von 1.247 und eine Wirkung von 1,3 sehen gründlich aus und enthalten nicht mehr Information als 1.200 und 1. Es wird großzügig gerundet.

Der zweite ist, Einträge zu bewerten, die man schon bauen will. Dann werden die Scores so lange zurechtgerückt, bis der Favorit gewinnt, und die Übung liefert nur Rückendeckung.

Der dritte ist, zu ignorieren, wer gefragt hat. RICE zählt Menschen, also schlägt ein Request von zehn kleinen Konten den Request eines einzelnen Kontos, das mehr wert ist als alle zehn zusammen. Wenn Umsatz zählt, kommt eine Spalte dafür dazu, die neben dem Score gelesen wird. Die Gewichtung nach Konto steht in Feature-Requests priorisieren.

Der vierte ist, Scores über verschiedene Zeitfenster oder die Skalen verschiedener Teams hinweg zu vergleichen. Es bleibt bei einer Tabelle, einem Zeitfenster und einem Satz Definitionen.

Wann sollte man etwas anderes als RICE verwenden?

Fehlen Reichweitendaten, hilft ICE (Impact, Confidence, Ease), das die Reichweite weglässt und den Aufwand durch eine Einfachheitsnote ersetzt, was gröber ausfällt. Geht es darum, welche Art von Wert ein Feature trägt statt wie viel, klassifiziert das Kano-Modell Requests als Basis-, Leistungs- oder Begeisterungsmerkmale, und beide lassen sich gut kombinieren. Betrifft die Entscheidung Reihenfolge und Zeitpunkt statt Rangfolge, passt ein Roadmap-Format besser, und Product Roadmap erstellen behandelt es.

Wie hält man RICE-Scores über die Zeit ehrlich?

Die Eingaben werden neben dem Score gespeichert, nicht nur das Ergebnis, damit jeder sieht, welche Annahme einen Rang bestimmt hat. Ein Eintrag wird neu bewertet, wenn sich seine Fakten ändern, etwa weil eine neue Welle von Requests die Reichweite hebt oder eine Entwicklerin merkt, dass sich der Aufwand verdoppelt hat. Nach dem Ausliefern werden die vorhergesagte Reichweite und Wirkung mit dem verglichen, was passiert ist, und die Schätzweise des Teams wird angepasst. Das Rohmaterial für die Reichweite ist die gruppierte, beschriftete Request-Liste aus Feature-Request-Tracking, und das Ergebnis gehört in die Antwort an die Leute, die gefragt haben.

FAQ

Was ist ein guter RICE-Score? Eine allgemeingültige Schwelle gibt es nicht, weil die Zahl von Reichweitenfenster und Aufwandseinheit abhängt. Scores werden nur innerhalb einer Tabelle verglichen, und das Ergebnis ist die Rangfolge, nicht der absolute Wert.

Was ist der Unterschied zwischen RICE und ICE? ICE multipliziert Impact, Confidence und Ease und lässt die Reichweite weg. Es ist schneller auszufüllen und ungenauer, wenn Features sehr unterschiedlich viele Nutzer betreffen, und genau dafür wurde RICE gemacht.

Wie schätzt man die Reichweite eines Feature-Requests? Man beginnt mit der Zahl der Konten, die ihn gestellt haben, addiert den Anteil aktiver Konten, die das Feature ungefragt nutzen würden, und gibt die Summe pro Quartal an. Ist die Schätzung grob, senkt man den Vertrauensfaktor, statt Präzision zu erfinden.

Sollte man jeden Feature-Request mit RICE bewerten? Nein. Das Scoring lohnt sich für die Handvoll Einträge, die so dicht beieinanderliegen, dass sie einen Tiebreaker brauchen. Offensichtliche Gewinner und offensichtliche Absagen lassen sich ohne entscheiden.

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.

Mehr bei changeloop: Entwicklerdokumentation, Changelog-Tools im Vergleich