Backlog qui pourrit : le nettoyer sans y passer la journée

Pourquoi votre backlog pourrit (et ce n'est pas votre faute)

Un backlog commence toujours propre. Vingt items, une équipe qui sait pourquoi chacun est là. Puis il grandit. À 200 items, il devient pénible. Au-delà de 500, il devient un passif.

Le problème n'est pas le volume. C'est que tout y est au même niveau. Une migration d'authentification et un changement de couleur de bouton se retrouvent côte à côte, à se disputer le même slot de priorité. Comme le résume un Head of Product cité par ProdPad, son backlog était devenu « un cimetière avec une barre de recherche » : plus de 400 items accumulés sur deux ans, tous taggés « idées ».

Quand tout est à plat, trois travers reviennent systématiquement :

• La priorisation au volume. L'item avec le plus de votes ou l'avocat le plus bruyant gagne. Une friction UI mineure mentionnée dix fois passe devant une décision d'architecture que personne hors engineering ne comprend.
• Le biais de récence. Ce dont on a parlé le plus récemment paraît le plus important. Le backlog devient une file d'attente, plus un outil de stratégie.
• La fausse équivalence. On applique le même scoring RICE à tout, comme si le « Reach » d'une migration de plateforme signifiait la même chose que celui d'une infobulle. Le chiffre donne une illusion de rigueur, mais les entrées ne sont pas comparables.

La bonne nouvelle : vous n'avez pas besoin d'une réunion de trois heures pour rattraper ça. Trois passes courtes, répétées régulièrement, suffisent.

Passe 1 — Supprimer : 20 minutes, pas de débat

Objectif : retirer tout ce qui ne sera jamais fait. Règle simple : si personne ne peut nommer un utilisateur ou un objectif concret que cet item sert, il sort.

Concrètement, vous supprimez :

• Les items créés il y a plus de six mois, jamais priorisés, dont personne ne se souvient.
• Les idées copiées-collées d'un fil Slack, sans contexte ni problème identifié.
• Les « on devrait peut-être… » sans propriétaire ni échéance.
• Les doublons déguisés (on y revient en passe 2).

Ne cherchez pas à archiver proprement. Supprimez. Si l'idée était bonne, elle reviendra — et cette fois avec un vrai problème derrière.

Dans un outil comme Ever Earlier, cette passe est mécanique : vous filtrez par date de création et par absence de priorité, vous supprimez en masse. Pas de réunion, pas de tableau Excel à maintenir.

Passe 2 — Fusionner : repérer les doublons et les regrouper

Après la suppression, il reste souvent des items qui décrivent le même besoin sous trois angles différents. C'est normal : trois personnes ont rencontré le même problème à trois moments.

La fusion se fait au niveau du problème, pas de la solution. Deux items qui proposent des solutions différentes au même problème n'en font qu'un.

Exemple concret. Trois items séparés :

• « Pouvoir voir qui a modifié une carte »
• « Historique des changements sur une tâche »
• « Savoir quand une story a été déplacée »

Un seul problème : la traçabilité des modifications. Une seule user story après fusion, avec un critère d'acceptation clair : « En tant que chef de projet, je vois la liste chronologique des modifications d'une carte, avec auteur et date, pour comprendre ce qui a changé depuis ma dernière visite. »

Dans Ever Earlier, le journal d'activité couvre déjà ce besoin côté outil — mais l'exercice vaut pour votre propre backlog. Une story fusionnée, avec priorité, points et critères d'acceptation, remplace trois items flous. Vous divisez le bruit par trois.

Passe 3 — Prioriser : valeur d'abord, taille ensuite

Il reste maintenant des items qui méritent une décision. Deux questions, dans cet ordre :

1. Quelle valeur ? Qui est impacté, combien, et à quel point ? Si vous ne pouvez pas répondre en une phrase, l'item n'est pas prêt — il retourne en discussion, pas en sprint.
2. Quelle taille ? Une story de 13 points qui traîne depuis trois sprints n'est pas une story, c'est un projet déguisé. Découpez-la.

C'est là que les user stories structurées font gagner du temps. Une story avec priorité, estimation en points et critères d'acceptation se juge en trente secondes. Une story sans ces éléments déclenche une discussion de dix minutes à chaque planning.

Un principe utile, tiré de la théorie des contraintes : ne surchargez pas le goulot. Si votre équipe merge ou livre 20 à 35 items par mois, un backlog actif de 200 items représente environ 6,7 mois d'attente en moyenne. Ce n'est pas un backlog temporaire, c'est ce que le système produit à cette charge. Réduire le travail en cours est plus efficace qu'ajouter des revues.

Le refactoring ne va pas au backlog

Tentation classique après un gros nettoyage : ajouter des « stories de refactoring » pour rattraper le retard technique. Ron Jeffries explique pourquoi c'est une mauvaise idée : demander du temps au product owner pour réparer ce qu'on a soi-même abîmé est difficile à vendre, et le résultat déçoit — on nettoie ce qu'on voit, dans le temps qu'on a, jamais assez.

La bonne approche est plus simple : à chaque nouvelle feature, on nettoie le code qu'on traverse. On ne détourne pas autour des ronces, on en défriche une partie. Parfois la feature prend un peu plus longtemps. Souvent non, parce que le nettoyage aide dès la première feature qui passe par là.

Conséquence pour votre backlog : n'y mettez pas de lignes « refactoring ». Mettez-y des features, et laissez le nettoyage se faire à l'intérieur.

La cadence compte plus que la profondeur

Une passe de 20 minutes toutes les deux semaines vaut mieux qu'une session de trois heures tous les six mois. Le backlog ne se salit pas d'un coup, il ne se nettoie pas d'un coup non plus.

Trois règles pour tenir :

• Une passe, un objectif. Supprimer, c'est supprimer. On ne priorise pas pendant qu'on supprime.
• Un responsable par passe. En général le product manager ou le chef de projet, pas toute l'équipe.
• Un outil qui ne rajoute pas de friction. Si nettoyer le backlog demande plus d'efforts que de le remplir, vous ne le ferez pas.

Dans Ever Earlier, les user stories avec priorité, points et critères d'acceptation rendent cette passe rapide : vous voyez immédiatement quels items sont prêts, lesquels sont vagues, lesquels n'ont plus de sens. Le backlog et les sprints vivent au même endroit, donc vous ne dupliquez rien.