Prioriser un backlog produit : 4 méthodes simples et efficaces
Un backlog qui grossit plus vite qu’il ne se vide est le symptôme le plus courant des projets digitaux. La solution n’est pas de travailler plus, mais de prioriser mieux. Voici quatre méthodes simples que j’utilise selon les contextes, et la façon de les faire vivre dans la durée.
Tolotra RamanantoaninaProduct Owner freelance · Okire ServicesFreelance Product Owner · Okire ServicesArticle en françaisThis article is available in French only
Avant de prioriser : préparer le backlog
Aucune méthode ne fonctionne sur un backlog confus. Avant d’arbitrer, il faut faire le ménage : fusionner les doublons, supprimer les demandes obsolètes et reformuler chaque élément sous forme de problème à résoudre plutôt que de solution imposée.
Il faut aussi savoir à quel objectif on rattache la priorisation. Prioriser « dans l’absolu » n’a pas de sens : on priorise pour réduire les erreurs de préparation, pour améliorer la satisfaction client ou pour préparer un pic d’activité. Sans objectif clair, chaque partie prenante défendra sa propre urgence.
Enfin, il est utile de disposer d’une estimation grossière de l’effort, même en tailles de t-shirt (S, M, L). Elle se construit avec l’équipe de développement, lors des séances d’affinage du backlog.
Méthode 1 : MoSCoW, simple et parlante pour le métier
MoSCoW classe chaque élément dans quatre catégories : Must have (indispensable), Should have (important mais pas vital), Could have (souhaitable si on a le temps) et Won’t have (pas pour cette fois).
Sa force est sa simplicité : tout le monde la comprend, y compris des interlocuteurs non techniques. C’est la méthode idéale pour cadrer un MVP ou une release avec la direction et les équipes métier.
Son piège : si tout devient « Must », elle ne sert plus à rien. Une règle utile consiste à limiter les Must à environ la moitié de la capacité disponible, pour garder de la marge face aux imprévus.
Méthode 2 : RICE, pour objectiver les arbitrages
RICE attribue un score à chaque sujet à partir de quatre critères : la portée (Reach, combien d’utilisateurs sont concernés), l’impact (de minime à massif), la confiance (à quel point on est sûr de ses estimations) et l’effort. Le score se calcule ainsi : portée × impact × confiance, divisé par l’effort.
L’intérêt de RICE est de rendre les débats plus factuels et de mettre en évidence les sujets à fort impact pour un effort raisonnable. Le critère de confiance est particulièrement précieux : il pénalise les idées séduisantes mais peu étayées, et incite à aller chercher des données avant de décider.
Sa limite : la précision des chiffres peut donner une fausse impression de rigueur. RICE sert à alimenter la discussion, pas à la remplacer.
Méthode 3 : la matrice valeur / effort, pour repérer les quick wins
Plus visuelle, la matrice valeur/effort place chaque élément sur deux axes. On obtient quatre zones : les quick wins (forte valeur, faible effort) à traiter en premier, les gros chantiers (forte valeur, effort important) à planifier, les petites améliorations (faible valeur, faible effort) à glisser quand il reste du temps, et les pièges (faible valeur, effort important) à écarter.
C’est la méthode que j’utilisais le plus chez By Charlot, dans un contexte de forte croissance où les besoins urgents s’accumulaient. Nous avions deux rythmes : deux à trois jours de développement pour les quick wins, et des sprints de deux semaines pour les sujets plus lourds. Ce double rythme permettait de soulager rapidement le terrain tout en avançant sur les chantiers structurants du WMS.
Méthode 4 : le modèle de Kano, pour penser satisfaction utilisateur
Le modèle de Kano distingue trois types de fonctionnalités. Les attentes de base ne créent pas de satisfaction quand elles sont présentes, mais provoquent un fort mécontentement quand elles manquent. Les fonctionnalités de performance augmentent la satisfaction à mesure qu’elles s’améliorent. Les fonctionnalités attractives surprennent et enchantent, mais personne ne les réclame.
Kano est utile pour éviter deux erreurs : surinvestir dans des attentes de base déjà satisfaites, et oublier qu’une fonctionnalité de base manquante peut ruiner l’expérience, quelle que soit la qualité du reste. On l’alimente idéalement avec un questionnaire auprès des utilisateurs.
Exemple concret : prioriser dix demandes en une heure
Imaginons un atelier avec les responsables de l’entrepôt, du service client et de l’e-commerce, face à dix demandes en attente. Plutôt que de débattre de chaque sujet, on procède en trois temps.
Premier temps, quinze minutes : chacun présente ses demandes en une phrase, sous la forme d’un problème (« les préparateurs perdent du temps à chercher les produits en rupture ») et non d’une solution. Deuxième temps, vingt minutes : on place chaque demande sur la matrice valeur/effort, avec l’aide d’un développeur pour l’effort. Troisième temps, vingt-cinq minutes : on applique MoSCoW aux demandes à forte valeur pour décider ce qui entre dans le prochain cycle.
- Résultat : deux ou trois quick wins à lancer immédiatement
- Un gros chantier à cadrer plus finement avant de le planifier
- Des demandes écartées, avec une raison expliquée à leur auteur
- Un backlog plus court, compris et accepté par toutes les équipes
L’essentiel n’est pas l’outil mais la transparence : chacun repart en sachant pourquoi sa demande passe avant ou après celle d’un collègue.
Quelle méthode choisir selon votre contexte ?
Il n’existe pas de méthode universelle. En pratique :
- Pour cadrer un MVP ou une release avec des interlocuteurs non techniques : MoSCoW
- Pour arbitrer entre de nombreuses idées avec des données disponibles : RICE
- Pour soulager rapidement les équipes tout en planifiant les chantiers : valeur / effort
- Pour un produit grand public ou centré sur l’expérience utilisateur : Kano
- Pour classer un petit nombre de problèmes stratégiques : un stack ranking, où l’on ordonne les sujets du premier au dernier sans ex aequo
Lors de la mission de discovery pour Vélib’, nous avons combiné plusieurs approches : un stack ranking pour identifier le problème prioritaire, puis une matrice d’Eisenhower pour ordonner les user stories du MVP. Le détail est dans l’étude de cas Vélib’.
Faire vivre la priorisation dans la durée
Prioriser n’est pas un exercice ponctuel. Le backlog doit être revu régulièrement, idéalement lors d’une séance d’affinage à chaque sprint, avec l’équipe et si possible un représentant du métier. Les priorités changent avec le contexte : un pic d’activité, un retour client, une nouvelle contrainte réglementaire.
Deux règles simples aident beaucoup. D’abord, garder un backlog court : seuls les éléments des prochains sprints doivent être détaillés, le reste peut rester à l’état d’idée. Ensuite, rendre les arbitrages visibles : expliquer pourquoi un sujet passe devant un autre désamorce une grande partie des tensions.
Et quand l’incertitude est trop forte pour prioriser sereinement, c’est souvent le signe qu’il faut d’abord mener une phase de discovery.
Questions fréquentes
Qui priorise le backlog produit ? Le Product Owner, qui en est le seul responsable. Il s’appuie sur le métier, les utilisateurs, les données et l’équipe de développement, mais c’est à lui de trancher.
À quelle fréquence faut-il reprioriser ? À chaque sprint, lors de la séance d’affinage. Les grandes orientations peuvent être revues chaque mois ou chaque trimestre avec la direction.
Combien d’éléments doit contenir un backlog ? Il n’y a pas de chiffre idéal, mais seuls les éléments des deux ou trois prochains sprints doivent être détaillés. Un backlog de plusieurs centaines d’éléments n’est plus pilotable.
Besoin d’un regard extérieur sur votre produit ?Need an outside view on your product?
Je suis Tolotra, Product Owner freelance. Parlons de votre projet en 30 minutes, sans engagement.I’m Tolotra, a freelance Product Owner. Let’s talk about your project in 30 minutes, no commitment.
