Expliquez-moi comment vous noteriez un backlog avec RICE, et dites-moi où ce framework montre ses limites.

RICE note chaque élément comme reach fois impact fois confidence, divisé par effort, ce qui vous donne un nombre comparable au lieu d'une dispute. Il tombe à l'eau sur tout ce qui est stratégique : une migration de plateforme ou une échéance de conformité a un reach lamentable et un effort énorme, donc elle perd toujours. Servez-vous de RICE pour classer du travail de fonctionnalité comparable, puis réservez à part une capacité fixe pour le travail stratégique et de maintenance.

Je me sers de RICE comme d'un premier passage, pas d'un verdict. Reach fois impact fois confidence sur effort, et j'insiste pour que le reach vienne de vrais chiffres, donc combien de comptes touchent réellement ce parcours dans le mois plutôt qu'une impression. Le multiplicateur de confiance est la partie utile, parce qu'il force quelqu'un à admettre que le chiffre d'impact est une estimation. Là où ça s'écroule, c'est tout ce qui n'est pas une fonctionnalité. On avait une migration de base de données qui frôlait le zéro en reach et l'énorme en effort, donc elle a perdu contre tout pendant deux trimestres, et ensuite on a passé six semaines de travail non prévu sur des incidents qu'elle avait causés. Après ça, j'ai arrêté de mettre l'infrastructure et la conformité dans la même liste. On a sanctuarisé environ un cinquième de la capacité pour ce travail et on ne notait plus que le travail de fonctionnalité discrétionnaire. Les chiffres cessent aussi d'être honnêtes dès que les gens comprennent comment ils servent, donc je traite un paquet de scores très serrés comme une égalité et je tranche au jugement.