RICE scoring: formule, rekenvoorbeeld en valkuilen

RICE scoring rangschikt productideeën met één getal: bereik maal impact maal vertrouwen, gedeeld door moeite. Een hogere score betekent meer verwachte waarde per eenheid werk. De methode komt van het productteam van Intercom en is een standaardmanier geworden om featureverzoeken te vergelijken die je niet op onderbuikgevoel uit elkaar kunt halen. Ze werkt het best op een korte lijst serieuze kandidaten, en ze is maar zo goed als de schattingen die erin gaan.

Wat is de RICE-scoreformule?

De score is Bereik × Impact × Vertrouwen ÷ Moeite. Bereik, impact en vertrouwen worden vermenigvuldigd omdat elk de opbrengst schaalt, en moeite deelt omdat dezelfde opbrengst meer kost als er meer werk voor nodig is. Kies voor bereik één tijdvenster, zoals een kwartaal, en gebruik het voor elk item, anders zijn de scores niet vergelijkbaar.

Het oorspronkelijke artikel van Intercom definieert de schalen uit de tabel hierboven, en de meeste teams laten ze ongewijzigd zodat scores tussen mensen vergelijkbaar blijven.

Hoe scoor je elke RICE-factor?

Bereik komt uit data die je al hebt. Begin bij een featureverzoek met het aantal verschillende accounts dat erom vroeg, en tel daar een schatting bij op van de accounts die het zonder te vragen zouden gebruiken. Impact is de minst nauwkeurige factor, dus gebruik de schaal van vijf waarden en weersta de neiging om decimalen te verzinnen. Vertrouwen is een korting voor gokken: gebruik 100% alleen met gebruiksdata of een getest prototype, 80% bij sterke signalen en 50% als je vooral gist. Moeite is de tijd van iedereen die erbij betrokken is, ontwerp en testen inbegrepen, in persoonmaanden.

Twee mensen die hetzelfde item scoren, horen bij elke factor binnen één stap van elkaar uit te komen. Zo niet, dan wordt het item niet goed genoeg begrepen om te rangschikken, en is het meningsverschil de bevinding.

Hoe ziet een RICE-scorevoorbeeld eruit?

Neem vier verzoeken uit een bijgehouden backlog, gescoord over één kwartaal.

Reken de eerste rij door: 400 × 1 × 0,8 ÷ 1 = 320. Donkere modus bereikt drie keer zoveel mensen, maar elk van hen wint er weinig mee, dus het komt net onder de export uit. De Slack-integratie heeft een goede impactscore die het vertrouwen halveert, wat zegt dat de volgende stap onderzoek is, geen bouwen.

Single sign-on staat onderaan, en dat verdient een tweede blik. Zestig accounts is een klein bereik, maar als dat de grotere accounts zijn en meerdere verlengingen van de feature afhangen, mist de score iets wat de methode niet kan zien.

Wat zijn de veelgemaakte RICE-fouten?

De eerste is schijnnauwkeurigheid. Een bereik van 1.247 en een impact van 1,3 zien er rigoureus uit en bevatten niet meer informatie dan 1.200 en 1. Rond ruim af.

De tweede is het scoren van items waarvan je al hebt besloten dat je ze bouwt. De scores worden dan bijgesteld totdat de favoriet wint, en de oefening levert alleen dekking op.

De derde is negeren wie het vroeg. RICE telt mensen, dus een verzoek van tien kleine accounts scoort hoger dan een verzoek van één account dat meer waard is dan alle tien samen. Telt omzet mee, voeg dan een kolom ervoor toe en lees die naast de score. Wegen naar account staat in featureverzoeken prioriteren.

De vierde is scores vergelijken over verschillende tijdvensters of de schalen van verschillende teams. Houd één sheet, één venster en één set definities aan.

Wanneer gebruik je iets anders dan RICE?

Heb je geen bereikdata, gebruik dan ICE (impact, vertrouwen, gemak), dat bereik weglaat en moeite vervangt door een gemakscore, en accepteer dat het ruwer is. Gaat de vraag over welk soort waarde een feature heeft in plaats van hoeveel, dan classificeert het Kano-model verzoeken als basis-, prestatie- of verrassingsfeatures, en de twee combineren goed. Gaat de beslissing over volgorde en timing in plaats van rangschikking, dan past een roadmapformaat beter, en een product roadmap maken behandelt dat.

Hoe houd je RICE-scores eerlijk in de loop van de tijd?

Bewaar de invoer naast de score, niet alleen de uitkomst, zodat iedereen kan zien welke aanname een plaats bepaalde. Kijk opnieuw naar een item als de feiten veranderen, bijvoorbeeld door een nieuwe batch verzoeken die het bereik verhoogt, of een engineer die ziet dat de moeite verdubbeld is. Vergelijk na het uitbrengen het voorspelde bereik en de voorspelde impact met wat er gebeurde en pas aan hoe je team de volgende keer schat. De grondstof voor bereik is de gegroepeerde, gelabelde verzoekenlijst uit featureverzoeken bijhouden, en het resultaat hoort in het antwoord dat je stuurt aan de mensen die erom vroegen.

FAQ

Wat is een goede RICE-score? Er is geen universele drempel, omdat het getal afhangt van je bereikvenster en moeite-eenheid. Vergelijk scores alleen binnen één sheet en behandel de rangschikking, niet de absolute waarde, als de uitkomst.

Wat is het verschil tussen RICE en ICE scoring? ICE vermenigvuldigt impact, vertrouwen en gemak en laat bereik weg. Het is sneller in te vullen en minder nauwkeurig als features zeer uiteenlopende aantallen gebruikers raken, het geval waarvoor RICE is ontworpen.

Hoe schat je het bereik voor een featureverzoek? Begin met het aantal accounts dat erom vroeg, tel het aandeel actieve accounts erbij dat het ongevraagd zou gebruiken, en druk het totaal uit per kwartaal. Is de schatting ruw, verlaag dan de vertrouwensfactor in plaats van nauwkeurigheid te verzinnen.

Moet elk featureverzoek met RICE worden gescoord? Nee. Scoren is de moeite waard voor de handvol items die dicht genoeg bij elkaar liggen om een beslisser nodig te hebben. Duidelijke winnaars en duidelijke afwijzingen kun je zonder beslissen.

De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.

Meer op changeloop: Documentatie voor ontwikkelaars, Changelog-tools vergeleken