Scoring RICE : formule, exemple chiffré et pièges à éviter

Le scoring RICE classe les idées produit avec un seul nombre : portée fois impact fois confiance, divisé par l’effort. Un score plus élevé signifie plus de valeur attendue par unité de travail. La méthode vient de l’équipe produit d’Intercom et est devenue un moyen courant de comparer des demandes de fonctionnalités que l’intuition ne permet pas de départager. Elle fonctionne mieux sur une courte liste de candidates sérieuses, et elle ne vaut que ce que valent les estimations qu’on lui donne.

Quelle est la formule du scoring RICE ?

Le score est Reach × Impact × Confidence ÷ Effort. La portée, l’impact et la confiance se multiplient parce que chacun met à l’échelle le gain, et l’effort divise parce que le même gain coûte plus cher quand il demande plus de travail. Choisissez une seule fenêtre de temps pour la portée, par exemple un trimestre, et utilisez-la pour tous les éléments, sinon les scores ne seront pas comparables.

L’article original d’Intercom définit les échelles du tableau ci-dessus, et la plupart des équipes les gardent telles quelles pour que les scores restent comparables d’une personne à l’autre.

Comment noter chaque facteur RICE ?

La portée vient de données que vous avez déjà. Pour une demande de fonctionnalité, partez du nombre de comptes distincts qui l’ont demandée, puis ajoutez une estimation des comptes qui l’utiliseraient sans l’avoir demandée. L’impact est le facteur le moins précis : utilisez l’échelle à cinq valeurs et résistez à l’envie d’inventer des décimales. La confiance est une décote pour les suppositions : prenez 100 % seulement si vous avez des données d’usage ou un prototype testé, 80 % si vous avez de forts signaux, et 50 % si vous devinez surtout. L’effort est le temps de tous les intervenants, design et tests compris, en personnes-mois.

Deux personnes qui notent le même élément devraient tomber à un cran d’écart l’une de l’autre sur chaque facteur. Sinon, l’élément n’est pas assez bien compris pour être classé, et le désaccord est le résultat.

À quoi ressemble un exemple de scoring RICE ?

Prenez quatre demandes d’un backlog suivi, notées sur un trimestre.

Détaillons la première ligne : 400 × 1 × 0,8 ÷ 1 = 320. Le mode sombre touche trois fois plus de monde, mais chacun y gagne peu, il atterrit donc juste sous l’export. L’intégration Slack a un bon score d’impact que la confiance divise par deux, ce qui indique que la prochaine étape est la recherche, pas le développement.

L’authentification unique arrive dernière, et cela mérite un second regard. Soixante comptes, c’est une petite portée, mais si ce sont les plus gros comptes et que plusieurs renouvellements dépendent de la fonctionnalité, le score ignore quelque chose que la méthode ne peut pas voir.

Quelles sont les erreurs courantes avec RICE ?

La première est la fausse précision. Une portée de 1 247 et un impact de 1,3 paraissent rigoureux et n’apportent pas plus d’information que 1 200 et 1. Arrondissez franchement.

La deuxième est de noter des éléments que vous avez déjà décidé de construire. Les scores sont alors ajustés jusqu’à ce que le favori gagne, et l’exercice ne produit que de la couverture.

La troisième est d’ignorer qui a demandé. RICE compte des personnes, donc une demande venant de dix petits comptes l’emporte sur celle d’un seul compte qui vaut plus que les dix réunis. Quand le revenu compte, ajoutez une colonne pour lui et lisez-la à côté du score. La pondération par compte est traitée dans comment prioriser les demandes de fonctionnalités.

La quatrième est de comparer des scores issus de fenêtres de temps différentes ou des échelles de différentes équipes. Gardez une seule feuille, une seule fenêtre et un seul jeu de définitions.

Quand utiliser autre chose que RICE ?

Quand vous n’avez aucune donnée de portée, utilisez ICE (impact, confiance, facilité), qui supprime la portée et remplace l’effort par une note de facilité, en acceptant que ce soit plus approximatif. Quand la question est de savoir quel type de valeur apporte une fonctionnalité plutôt que combien, le modèle de Kano classe les demandes en fonctionnalités indispensables, de performance ou attractives, et les deux se combinent bien. Quand la décision porte sur l’ordre et le calendrier plutôt que sur le classement, un format de roadmap convient mieux, et comment construire une roadmap produit en parle.

Comment garder des scores RICE honnêtes dans la durée ?

Conservez les données d’entrée à côté du score, pas seulement le résultat, pour que chacun voie quelle hypothèse a fait un classement. Revoyez un élément quand ses faits changent, par exemple un nouveau lot de demandes qui fait monter la portée, ou un ingénieur qui constate que l’effort a doublé. Après la livraison, comparez la portée et l’impact prévus avec ce qui s’est passé, et ajustez la façon dont votre équipe estime la fois suivante. La matière première de la portée est la liste de demandes regroupées et étiquetées décrite dans le suivi des demandes de fonctionnalités, et le résultat a sa place dans la réponse que vous envoyez aux personnes qui ont demandé.

FAQ

Qu’est-ce qu’un bon score RICE ? Il n’existe pas de seuil universel, car le nombre dépend de votre fenêtre de portée et de votre unité d’effort. Comparez les scores uniquement dans une même feuille, et considérez que le résultat attendu est le classement, pas la valeur absolue.

Quelle est la différence entre le scoring RICE et ICE ? ICE multiplie l’impact, la confiance et la facilité, et laisse de côté la portée. Il se remplit plus vite et il est moins précis quand les fonctionnalités touchent des nombres d’utilisateurs très différents, ce qui est le cas pour lequel RICE a été conçu.

Comment estimer la portée d’une demande de fonctionnalité ? Partez du nombre de comptes qui l’ont demandée, ajoutez la part des comptes actifs susceptibles de l’utiliser spontanément, et exprimez le total par trimestre. Si l’estimation est grossière, baissez le facteur de confiance au lieu d’inventer de la précision.

Faut-il noter toutes les demandes de fonctionnalités avec RICE ? Non. Le scoring vaut l’effort pour la poignée d’éléments assez proches pour avoir besoin d’un départage. Les évidences à retenir comme à rejeter peuvent se décider sans lui.

Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Documentation développeurs, Comparatif d'outils de changelog