La priorisation produit repose sur un problème simple : trop de demandes, pas assez de capacité. Le feature by feature et le scoring RICE répondent à deux moments distincts de ce tri. Le premier filtre les demandes brutes avant qu’elles n’entrent dans un tableur. Le second attribue un score comparable à chaque idée retenue. Utilisés séparément, chacun laisse un angle mort. Combinés dans le bon ordre, ils raccourcissent la décision sans multiplier les réunions.
Pré-tri feature by feature : filtrer avant de scorer
Le feature by feature n’est pas un framework de scoring. C’est une étape de qualification qui intervient en amont, quand le backlog contient encore des demandes floues, des doublons et des idées sans lien avec un objectif mesurable.
Le principe consiste à examiner chaque demande individuellement et à vérifier qu’elle remplit un minimum de conditions avant de mériter un calcul. Concrètement, chaque demande doit être reliée à un KPI précis : rétention à 30 jours, revenu récurrent, coût du délai, volume de tickets support. Si personne ne peut nommer l’indicateur qu’une fonctionnalité est censée améliorer, elle sort du lot.
Ce rattachement systématique à un indicateur opérationnel élimine souvent la moitié des idées d’un backlog gonflé. Les irritants remontés par le support, les avis utilisateurs et les données d’usage servent de sources pour alimenter ce filtre. Le scoring RICE ne devrait démarrer qu’après cette réduction.
Score RICE : un langage de comparaison, pas une vérité absolue
RICE attribue à chaque fonctionnalité un score calculé selon quatre critères : Reach (portée), Impact, Confidence (confiance dans les estimations) et Effort. La formule est directe :
RICE = (Reach x Impact x Confidence) / Effort
Reach estime le nombre d’utilisateurs touchés sur une période donnée. Impact évalue le changement attendu sur la métrique cible, souvent sur une échelle qualitative (minimal, faible, moyen, fort, massif). Confidence traduit le degré de certitude des estimations précédentes, exprimé en pourcentage. Effort représente le coût en temps-personne.
Le résultat produit un classement. Mais plusieurs sources récentes rappellent que RICE sert à comparer des idées de manière défendable, pas à trancher mécaniquement. Un score élevé fondé sur des estimations faibles vaut moins qu’un score moyen appuyé sur des données d’usage réelles. La variable Confidence existe précisément pour signaler ce risque.
Combiner pré-tri feature by feature et scoring RICE dans un workflow produit
L’enchaînement le plus efficace suit trois temps distincts. Le feature by feature agit comme filtre d’entrée, le scoring RICE comme outil de classement, et la contestation par la preuve comme garde-fou final.
Étape de qualification par le feature by feature
Avant toute réunion de priorisation, chaque demande passe un test binaire :
- Un KPI opérationnel identifié est rattaché à la fonctionnalité (rétention, revenu récurrent, coût du délai, volume de tickets).
- Au moins une source de données la soutient : retour support, donnée d’usage, feedback utilisateur documenté.
- La demande ne fait pas doublon avec une autre déjà qualifiée dans le backlog.
Les demandes qui échouent à ce test ne passent pas au scoring. Elles retournent dans un parking lot consultable, pas dans la corbeille.
Application du score RICE aux demandes qualifiées
Seules les fonctionnalités ayant franchi le pré-tri reçoivent un score. Cela réduit le nombre de lignes à évaluer et concentre l’effort d’estimation sur des sujets déjà ancrés dans un objectif.
Pour chaque critère RICE, la personne qui remplit la grille doit indiquer la source de son estimation. Une Confidence haute sans donnée d’appui est un signal d’alerte, pas une validation.
Contestation sur preuve avant arbitrage
Une pratique terrain qui renforce la fiabilité du processus : partager la grille RICE complète avant la réunion de décision. Toute personne souhaitant contester un score doit apporter une donnée ou un retour utilisateur concret. Les objections sans preuve ne modifient pas le classement.
Cette règle évite les débats d’opinion en réunion et recentre la discussion sur les faits. Elle protège aussi les scores des biais hiérarchiques, où la voix la plus forte l’emporte sur l’estimation la mieux documentée.
Risques de fausse précision dans le scoring RICE
Le principal piège de RICE appliqué sans pré-tri est la fausse précision. Multiplier Reach par Impact par Confidence puis diviser par Effort produit un chiffre rassurant, même quand chaque variable repose sur une intuition.
Deux fonctionnalités séparées par quelques points de score ne sont pas réellement départagées si les estimations sous-jacentes ont été posées sans données. Le pré-tri feature by feature réduit ce risque en éliminant les sujets pour lesquels aucune donnée n’existe. Si une demande n’a pas de KPI rattaché ni de source d’usage, lui attribuer un score RICE revient à quantifier du vide.
Un autre réflexe utile : traiter les scores proches comme équivalents et arbitrer entre eux sur un critère contextuel (alignement stratégique, dépendance technique, fenêtre de marché) plutôt que sur un écart de score non significatif.
Adapter la combinaison feature by feature et RICE à la taille de l’équipe
Pour une équipe produit de moins de cinq personnes, le pré-tri peut se faire de manière asynchrone dans un document partagé. Chaque demande reçoit une ligne avec trois colonnes : KPI rattaché, source de la demande, doublon oui/non. Le scoring RICE se fait ensuite sur un tableur simple.
- Équipes réduites : un seul document regroupe pré-tri et scoring, mis à jour en continu.
- Équipes moyennes : le pré-tri est réalisé par le product manager, le scoring est rempli collectivement lors d’un atelier dédié.
- Organisations avec plusieurs squads : chaque squad pré-filtre ses demandes, puis les scores RICE sont consolidés pour l’arbitrage inter-équipes.
L’objectif reste le même quelle que soit la taille : ne scorer que ce qui mérite d’être scoré. Ajouter une étape de qualification ne ralentit pas le processus. Elle supprime le bruit qui, sans filtre, transforme chaque réunion de priorisation en débat sans fin.
Le feature by feature et RICE ne sont pas deux méthodes concurrentes à choisir l’une contre l’autre. Le premier décide de ce qui entre dans le calcul, le second classe ce qui y est entré. Scorer moins de fonctionnalités avec de meilleures données produit des arbitrages plus rapides et plus défendables qu’un tableur exhaustif rempli d’estimations approximatives.
