Backlog produit : les erreurs à éviter (et le grooming qui marche)

Qu’est-ce qu’un backlog produit ?

Le backlog produit est la liste ordonnée de tout le travail connu sur le produit : fonctionnalités, user stories, corrections de bugs, changements de design, dette technique, demandes clients, actions issues des rétrospectives. C’est la traduction opérationnelle de la roadmap produit : la roadmap dit où l’on va, le backlog dit ce qu’il faut faire pour y aller.

Sa fonction première est d’alimenter la planification de sprint. Tout le travail doit y figurer, pour que l’équipe arbitre en connaissance de cause avec le product owner avant chaque itération. Ce qui n’est pas dans le backlog ne devrait pas être fait.

Ce qu’il contient

• Des user stories, rattachées à des epics de la roadmap.
• Des corrections de bugs, qualifiées par gravité.
• De la dette technique et des chantiers d’infrastructure.
• Des tâches de découverte : entretiens, prototypes, analyses de données.
• Des actions de rétrospective, pour que les améliorations ne restent pas des intentions.

Le haut du backlog est détaillé et prêt à être engagé. Le bas peut rester grossier. Plus un élément est loin dans le temps, moins il mérite d’effort de rédaction.

Comment prioriser

Le product owner ordonne le backlog selon la valeur, en croisant plusieurs critères :

1. La valeur pour l’utilisateur et pour l’entreprise.
2. L’alignement avec les objectifs stratégiques et les hypothèses à valider.
3. Les retours utilisateurs et ceux des équipes commerciales.
4. Le risque : ce qui réduit le plus d’incertitude passe souvent en premier.
5. L’effort et la capacité réelle de l’équipe.

Des grilles de scoring existent pour formaliser ces critères. Elles aident à objectiver une discussion, à condition de ne pas devenir un calcul qui remplace le jugement. Une priorité doit pouvoir s’expliquer en une phrase.

Une routine de tri pour les nouvelles demandes

La plupart des backlogs ne se dégradent pas en grooming. Ils se dégradent à l’entrée : chaque demande y est ajoutée telle quelle, sans décision. Le tri, ou triage, règle ce problème. C’est un rendez-vous court, distinct du grooming, où le product owner traite tout ce qui est arrivé depuis la dernière fois.

Chaque nouvel élément doit en sortir avec l’une de ces cinq décisions :

La dernière ligne est la plus difficile, et la plus importante. Un refus expliqué vaut mieux qu’un ticket qui dort deux ans : le demandeur sait où il en est, et il revient avec une meilleure demande. Comptez quinze minutes deux fois par semaine dans une petite équipe, un créneau quotidien quand les demandes arrivent de plusieurs équipes commerciales ou de clients nombreux.

Le backlog grooming qui marche

Le grooming, qu’on appelle aussi affinage ou refinement, est la séance régulière où l’équipe revoit le backlog. Son but : que le haut de la liste soit prêt pour le prochain sprint. Voici le format que je recommande :

1. Une séance courte et régulière, chaque semaine ou en milieu de sprint, plutôt qu’un marathon mensuel.
2. Le product owner prépare : il arrive avec les éléments à discuter déjà ordonnés et décrits.
3. L’équipe questionne et découpe : chaque élément trop gros est scindé, chaque élément flou est clarifié.
4. On estime grossièrement, pour vérifier que le haut du backlog tient dans la capacité.
5. On nettoie : ce qui n’a plus de sens est supprimé, ce qui est en double est fusionné.

Un élément est prêt quand l’équipe comprend le problème, sait comment vérifier qu’il est terminé, et peut le réaliser en un sprint.

Une séance, déroulée

Exemple fictif. Une équipe de six personnes qui développe un outil de réservation pour des salles de sport. Séance de quarante-cinq minutes en milieu de sprint, six éléments préparés par le product owner.

Bilan : trois éléments prêts, un découpé, un renvoyé en qualification, un supprimé. C’est une bonne séance. Une séance où tout est « prêt » sans question est souvent une séance où l’équipe n’a pas vraiment lu.

Les sept erreurs à éviter

1. Ne pas faire de grooming régulier. Le backlog se périme, et la planification de sprint devient une séance de découverte.
2. Ne mettre que du visible. Les éléments d’interface passent, la dette technique et la sécurité attendent jusqu’à l’incident.
3. Prioriser sans critère. L’ordre reflète la dernière personne qui a insisté, et l’équipe travaille sur des sujets à faible valeur.
4. Exclure les développeurs. On priorise des éléments irréalisables ou mal compris, et l’équipe se désengage.
5. Tout garder. Un backlog de plusieurs centaines d’éléments n’est plus un outil de décision. Supprimez ce qui n’a pas bougé depuis six mois : si c’est important, cela reviendra.
6. Confondre backlog et roadmap. Les user stories n’expliquent pas la direction. Sans roadmap au-dessus, le backlog n’a pas de sens.
7. Ne pas fermer la boucle. Un élément livré n’est pas terminé tant qu’on n’a pas vérifié qu’il a produit l’effet attendu.

Un diagnostic en dix minutes

Ouvrez votre backlog et vérifiez ces cinq points :

• Quelle part des éléments a plus de six mois ? Au-delà d’un tiers, le nettoyage est en retard.
• Combien d’éléments ne sont rattachés à aucune epic ni hypothèse ?
• Le haut de liste représente-t-il deux à trois sprints d’éléments prêts, ni moins, ni beaucoup plus ?
• Y trouve-t-on de la dette technique et de la sécurité dans les vingt premiers éléments ?
• Les éléments livrés le trimestre dernier ont-ils une mesure d’effet ?

Ces seuils sont des repères, pas des normes. Ce qui compte est leur évolution d’un mois sur l’autre.

Faire évoluer le backlog dans le temps

Le backlog évolue avec le produit. Des éléments pertinents au départ cessent de l’être après des retours clients ou un changement de marché. L’équipe documente au fil des tickets ce qu’elle a fait, ce qui a marché et ce qui n’a pas marché ; ces informations nourrissent la rétrospective et les sprints suivants.

Dans un outil comme Asana, un projet de backlog par équipe, relié au projet de roadmap, fonctionne bien. Je décris cette organisation dans créer une roadmap agile dans Asana.

Petite équipe ou grande organisation

Une équipe unique tient un seul backlog, et le product owner fait lui-même le tri. Quand plusieurs équipes travaillent sur le même produit, gardez un backlog par équipe, mais une seule porte d’entrée pour les demandes extérieures. Sinon, les commerciaux apprennent vite à déposer la même demande chez l’équipe la plus accommodante. Les dépendances entre équipes se traitent dans la roadmap agile, pas dans les backlogs.

Avec le recul

En relisant cet article écrit en 2022, je n’en retire rien de l’essentiel. Le backlog reste l’outil le plus utilisé et le plus mal tenu. Mais trois choses ont bougé dans ma pratique.

Ce que je garde

Le grooming court et régulier, et la suppression sans remords des éléments qui dorment. Chez Dotworld, où nous avons livré quatre SaaS en six mois, le rythme n’aurait pas tenu avec des backlogs encombrés : un backlog court est un backlog qu’on lit.

Ce que je nuance

J’ai sous-estimé le tri à l’entrée. Je parlais du grooming comme du moment où l’on nettoie ; je pense aujourd’hui que l’essentiel se joue avant, au moment où une demande entre. D’où la routine de tri ci-dessus, que je n’aurais pas écrite en 2022.

Je nuance aussi la règle « ce qui n’est pas dans le backlog ne devrait pas être fait ». Elle reste juste pour le travail de l’équipe produit. Mais une partie du travail sur un système IA, comme l’annotation d’exemples ou la mise à jour de contenus métier, est faite par des équipes extérieures au produit. Elle doit être visible, pas forcément dans le même backlog.

Ce que les assistants IA ont changé

Les assistants IA sont efficaces sur les tâches ingrates du backlog : repérer les doublons, regrouper des demandes similaires, proposer un premier découpage d’une epic, reformuler une user story floue. Ils rendent le tri plus rapide. Utilisez-les pour préparer le grooming, pas pour le remplacer : la discussion de l’équipe est ce qui crée la compréhension partagée.

Une précaution : un assistant qui reformule une user story peut y ajouter un critère que personne n’a demandé, avec beaucoup d’aplomb. Relisez chaque reformulation contre la demande d’origine. Le temps gagné se mesure en comptant cette relecture, comme je le recommande dans mesurer le gain de temps de l’IA.

Questions fréquentes

Qui est responsable du backlog produit ?

Le product owner, ou le product manager selon l’organisation. Il en décide l’ordre et en répond, mais toute l’équipe peut y proposer des éléments et participe à son affinage.

Quelle différence entre backlog grooming et sprint planning ?

Le grooming prépare : il clarifie, découpe et ordonne les éléments à venir. La planification de sprint engage : l’équipe choisit, parmi les éléments prêts, ce qu’elle réalisera pendant l’itération.

Combien d’éléments doit contenir un backlog ?

Il n’y a pas de chiffre idéal, mais deux à trois sprints d’éléments prêts en haut de liste suffisent. Au-delà, le détail se périme avant d’être utilisé.

Quelle différence entre le tri et le grooming ?

Le tri décide du sort de chaque nouvelle demande : la traiter, l’ordonner, la fusionner, la qualifier ou la refuser. Le grooming prépare avec l’équipe les éléments déjà retenus pour les prochains sprints.

Et l’IA dans tout ça ?

Pour un système IA en production, le backlog change de nature. Il contient des éléments que l’on ne voit pas dans un produit classique : catégories d’erreurs à corriger, nouveaux termes métier à intégrer, cas limites remontés par les équipes terrain, seuils de qualité à surveiller. Ces éléments viennent directement de la mesure, comme je l’explique dans mesurer un assistant IA de support. Un système IA sans backlog d’amélioration alimenté par le terrain se dégrade en silence.

La routine de tri s’applique telle quelle : une erreur qui expose l’entreprise se traite tout de suite, une catégorie d’erreurs récurrente s’ordonne, un cas isolé se qualifie. Le backlog d’amélioration est d’ailleurs ce qui distingue un système en production d’un POC laissé en l’état, le sujet de du POC IA à la production.