RICE scoring: formula, esempio pratico e errori comuni

Il RICE scoring ordina le idee di prodotto con un solo numero: reach per impact per confidence, diviso per effort. Un punteggio più alto significa più valore atteso per unità di lavoro. Il metodo nasce dal team prodotto di Intercom ed è diventato un modo standard per confrontare richieste di funzionalità che l’intuito non riesce a distinguere. Funziona meglio su una lista corta di candidati seri, e vale quanto valgono le stime che ci metti dentro.

Qual è la formula del RICE scoring?

Il punteggio è Reach × Impact × Confidence ÷ Effort. Reach, impact e confidence si moltiplicano perché ognuno scala il risultato, mentre effort divide perché lo stesso risultato costa di più quando richiede più lavoro. Scegli un’unica finestra di tempo per il reach, per esempio un trimestre, e usala per ogni voce, altrimenti i punteggi non sono confrontabili.

L’articolo originale di Intercom definisce le scale della tabella qui sopra, e la maggior parte dei team le lascia invariate perché i punteggi restino confrontabili tra persone diverse.

Come si assegna il punteggio a ogni fattore RICE?

Il reach viene da dati che hai già. Per una richiesta di funzionalità, parti dal numero di account distinti che l’hanno chiesta, poi aggiungi una stima degli account che la userebbero senza chiederla. L’impact è il fattore meno preciso, quindi usa la scala a cinque valori e resisti alla tentazione di inventare decimali. La confidence è uno sconto per le ipotesi: usa il 100% solo quando hai dati d’uso o un prototipo testato, l’80% quando hai segnali forti e il 50% quando in gran parte stai tirando a indovinare. L’effort è il tempo di tutte le persone coinvolte, design e test compresi, in persone-mese.

Due persone che valutano la stessa voce dovrebbero arrivare a un passo di distanza su ogni fattore. Se non succede, la voce non è capita abbastanza bene per essere ordinata, e il disaccordo è il risultato.

Com’è fatto un esempio di RICE scoring?

Prendi quattro richieste da un backlog tracciato, valutate su un trimestre.

Svolgi la prima riga: 400 × 1 × 0,8 ÷ 1 = 320. La modalità scura raggiunge il triplo delle persone, ma ciascuna ne ricava poco, quindi finisce appena sotto l’esportazione. L’integrazione con Slack ha un buon punteggio di impact che la confidence dimezza, e questo ti dice che il passo successivo è la ricerca, non lo sviluppo.

Il single sign-on è ultimo, e merita un secondo sguardo. Sessanta account sono un reach piccolo, ma se sono gli account più grandi e diversi rinnovi dipendono dalla funzionalità, al punteggio manca qualcosa che il metodo non riesce a vedere.

Quali sono gli errori comuni del RICE?

Il primo è la falsa precisione. Un reach di 1.247 e un impact di 1,3 sembrano rigorosi e non portano più informazione di 1.200 e 1. Arrotonda con decisione.

Il secondo è valutare voci che hai già deciso di costruire. I punteggi vengono allora ritoccati finché la favorita vince, e l’esercizio produce solo una copertura.

Il terzo è ignorare chi ha chiesto. RICE conta le persone, quindi la richiesta di dieci piccoli account supera quella di un solo account che vale più di tutti e dieci insieme. Quando i ricavi contano, aggiungi una colonna per quelli e leggila accanto al punteggio. Come pesare per account è trattato in come dare priorità alle richieste di funzionalità.

Il quarto è confrontare punteggi con finestre di tempo diverse o con le scale di team diversi. Tieni un solo foglio, una sola finestra e un solo insieme di definizioni.

Quando usare qualcosa di diverso dal RICE?

Quando non hai dati di reach, usa ICE (impact, confidence, ease), che elimina il reach e sostituisce l’effort con una valutazione di facilità, accettando che sia più grezzo. Quando la domanda è che tipo di valore porta una funzionalità invece di quanto, il modello Kano classifica le richieste in funzionalità obbligatorie, di prestazione o di piacere, e i due metodi si combinano bene. Quando la decisione riguarda ordine e tempistica invece della classifica, un formato di roadmap è più adatto, e come costruire una roadmap di prodotto lo spiega.

Come mantenere onesti i punteggi RICE nel tempo?

Conserva gli input accanto al punteggio, non solo il risultato, così chiunque può vedere quale ipotesi ha determinato una posizione. Rivedi una voce quando i suoi fatti cambiano, per esempio quando un nuovo gruppo di richieste fa salire il reach, o quando un ingegnere si accorge che l’effort è raddoppiato. Dopo il rilascio, confronta reach e impact previsti con quello che è successo e correggi il modo in cui il tuo team stima la volta dopo. La materia prima per il reach è l’elenco di richieste raggruppate ed etichettate descritto in tracciare le richieste di funzionalità, e il risultato va nella risposta che mandi a chi ha chiesto.

FAQ

Qual è un buon punteggio RICE? Non esiste una soglia universale, perché il numero dipende dalla tua finestra di reach e dall’unità di effort. Confronta i punteggi solo all’interno di un foglio e considera l’output la classifica, non il valore assoluto.

Qual è la differenza tra RICE e ICE? ICE moltiplica impact, confidence ed ease e lascia fuori il reach. È più rapido da compilare e meno accurato quando le funzionalità riguardano numeri molto diversi di utenti, che è il caso per cui è stato pensato RICE.

Come si stima il reach di una richiesta di funzionalità? Parti dal numero di account che l’hanno chiesta, aggiungi la quota di account attivi che la userebbe spontaneamente ed esprimi il totale a trimestre. Se la stima è approssimativa, abbassa il fattore di confidence invece di inventare precisione.

Ogni richiesta di funzionalità va valutata con RICE? No. Il punteggio vale la fatica per le poche voci abbastanza vicine da aver bisogno di uno spareggio. Le vittorie evidenti e i rifiuti evidenti si decidono senza.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Documentazione per sviluppatori, Strumenti di changelog a confronto