« Delete your backlog. »
Supprimez votre backlog.
C’est vrai que cela sonne comme une provocation gratuite. Un peu posture. Le genre de phrase qu’on lance pour faire réagir une salle. Et puis j’ai repensé à la dernière fois que j’avais ouvert le Jira d’une équipe que j’accompagnais : des centaines d’items, des tickets de 2022, des epics fantômes, des « à creuser » que plus personne ne pouvait dater. Et là, la “provocation gratuite” est devenue trés réelle et concrète !
Parce que pour beaucoup d’équipes produit, tech ou agiles, l’idée paraît presque irresponsable. Le backlog, après tout, est censé être la mémoire du produit. L’endroit où l’on stocke les demandes, les idées, les tickets techniques, les irritants clients, les besoins métier, les opportunités, les bugs, les promesses faites aux stakeholders, les hypothèses à creuser plus tard. Sauf qu’à force de vouloir tout conserver, beaucoup d’organisations ne construisent pas une mémoire produit. Elles construisent un cimetière.
Un cimetière d’idées mal formulées. De demandes jamais arbitrées. De « on verra plus tard ». De tickets que personne ne comprend plus. De dettes techniques dont personne ne sait si elles sont encore réelles. De fonctionnalités demandées par un stakeholder parti depuis trois réorganisations. De promesses implicites, jamais assumées comme telles. De priorités mortes, mais jamais enterrées.
Et ce cimetière a un coût.
Pas seulement un coût d’outil. Pas seulement un coût de refinement ou de maintenance Jira. Un coût cognitif, organisationnel, stratégique. Un backlog infini ne ralentit pas seulement l’équipe : il révèle souvent une incapacité plus profonde à choisir.
C’est tout l’enjeu de cet article. Le backlog n’est pas le problème. Il est le symptôme.
D’un outil de pilotage à un parking politique
À l’origine, un backlog est un outil utile, et je ne voudrais surtout pas qu’on me fasse dire le contraire. Il rend visible le travail à venir. Il aide à prioriser, à collaborer, à clarifier ce qui compte maintenant et ce qui pourrait compter demain. Dans un système sain, le backlog soutient la décision. Il aide à organiser l’incertitude.
Je me souviens quand Claude Aubry m’a formé au métier de PO en 2007-2008 : ce backlog était une vraie révolution salavatrice pour moi qui avait connu jusque là que les spécifications en 10 tommes !! Quel changement ! C’était léger, efficace : on écrivait sur des fiches bristol pour le bienfait de la contrainte des 3C (Card, Conversation, Confirmation) de Ron Jeffries, et on avait une petite pile de ces fiches pour échanger et construire avec les ingénieurs. Et puis, progressivement un peu partout j’ai vu le backlog devenir autre chose.
Il devient un parking politique.
On y met les demandes pour éviter de dire non. On y ajoute des idées pour ne pas les perdre. On y stocke les sujets « au cas où ». On y garde des tickets anciens parce qu’on n’ose pas les supprimer. On y laisse mourir des sujets sans jamais acter leur abandon.
Progressivement, le backlog cesse d’être un instrument de pilotage. Il devient une accumulation. Et cette accumulation produit trois effets très concrets, que je retrouve presque partout.
Le premier, c’est une charge mentale pour les Product Owners et Product Managers. Être responsable d’un backlog de plusieurs centaines, parfois milliers d’items, c’est porter une dette permanente. Même quand tout le monde sait pertinemment qu’une grande partie ne sera jamais traitée, le simple fait que ça existe continue à peser. J’ai vu des PM avoir un vrai blocage rien qu’à l’idée d’ouvrir leur outil le lundi matin.
Le deuxième, c’est la dégradation de la qualité des décisions. Plus le backlog est volumineux, plus la priorisation devient artificielle. On compare des choses incomparables : un ticket de 2023, une demande arrivée hier, un irritant technique, un engagement politique, une idée vague jetée en réunion. La discussion glisse du problème à résoudre vers la gestion d’un inventaire.
Le troisième, c’est le brouillage de la stratégie. Un backlog plein donne l’illusion que l’organisation sait ce qu’elle doit faire, alors qu’elle a seulement stocké ce qu’elle pourrait faire. Ce n’est pas la même chose. Pas du tout, même.
Une liste longue n’est pas une stratégie. Une collection de demandes n’est pas une vision produit. Un backlog rempli n’est pas une preuve de maturité.
Parfois, c’est même l’inverse.
Le backlog obèse ou infini casse le flux
On parle beaucoup de flow dans les organisations agiles. On optimise le flux de delivery, on mesure les temps de cycle, on traque les goulots d’étranglement, on essaie de fluidifier le passage de l’idée au produit livré.
Mais que se passe-t-il avant qu’un sujet arrive dans le sprint backlog ? Avant qu’il soit raffiné, estimé, découpé en user stories et construit par une équipe ?
Dans beaucoup d’organisations, l’amont est un entonnoir sans véritable discipline. Toutes les demandes entrent. Peu sont réellement qualifiées. Encore moins sont reliées explicitement à une stratégie, à un problème client, à une opportunité business, à une métrique d’impact ou à une hypothèse testable.
Le backlog devient alors un point de rupture du flux.
On croit que le flow commence quand l’équipe prend un item en sprint. En réalité, le flux de valeur commence bien avant : au moment où l’organisation formule un problème, choisit une direction, décide de ce qui mérite attention, et accepte de laisser tomber le reste.
Si tout entre dans le backlog, rien n’est vraiment choisi. Et si rien n’est vraiment choisi, l’équipe peut livrer vite et/ou beaucoup sans pour autant créer beaucoup de valeur.
C’est l’une des grandes confusions de l’agilité appliquée mécaniquement : on optimise le delivery sans jamais nettoyer le système de décision en amont. On améliore la cadence d’exécution tout en conservant une fabrique à priorités floues.
Le backlog devient l’endroit où l’organisation externalise son incapacité à décider.
« Si c’est important, ça reviendra »
L’idée de supprimer son backlog repose sur une hypothèse simple, et franchement assez inconfortable : si une idée est vraiment importante, elle refera surface.
Un besoin client critique reviendra. Une dette technique réellement problématique réapparaîtra : dans les incidents, dans la maintenabilité, dans la vélocité réelle, dans la difficulté à faire évoluer le produit. Une opportunité stratégique sérieuse se reformulera d’elle-même dans les discussions de roadmap, les objectifs business, les retours marché.
Ce qui ne revient jamais était peut-être moins important qu’on ne le croyait. C’est brutal. Mais ce n’est pas absurde.
Je tiens ici a préciser un deuxième point important parce que prise au pied de la lettre cette logique est dangereuse. Cette logique n’est est vraie qu’à une condition : que votre système soit capable de faire remonter ces signaux.Sans feedback client réel, sans observabilité technique, sans proximité avec le marché, “ça reviendra” devient une illusion dangereuse.
Sans sytème de feedback tout ne « revient » pas spontanément. Une dette technique silencieuse peut très bien ne jamais crier avant le jour où elle vous explose à la figure. Certains risques ne se manifestent qu’une fois. L’argument ne dit pas « ce qui disparaît ne valait rien » : il dit qu’une grande partie de ce qu’on conserve survit par inertie, pas par pertinence.
Et là est le vrai point. Dans les faits, beaucoup d’items survivent dans les backlogs non parce qu’ils sont encore pertinents, mais parce que personne ne veut prendre la responsabilité de les supprimer. Ils existent par prudence. Par peur du conflit. Par respect mal placé pour une conversation passée.
Supprimer un backlog, ou au moins le purger radicalement ou régulièrement, force à reposer les bonnes questions :
- Quel est notre produit, aujourd’hui ?
- Quelle valeur cherchons-nous vraiment à créer ?
- Quelle est notre stratégie actuelle ?
- Quels problèmes méritent notre attention maintenant ?
- Quelles opportunités sont encore vivantes ?
- Quelles demandes ne sont plus alignées avec la direction prise ?
- Qu’est-ce qui relève d’un vrai besoin, et qu’est-ce qui n’est qu’une trace administrative du passé ?
Ce n’est donc pas un geste de destruction. C’est un geste de clarification.
Le vrai sujet n’est pas de supprimer pour supprimer, c’est d’ancrer
Soyons clairs : il serait stupide de supprimer aveuglément tout le travail injecté dans votre backlog sans aucune précaution. On peut exporter, archiver, masquer, changer les filtres, créer un espace séparé pour l’historique. Personne ne demande de brûler les archives pour le plaisir du geste radical.
Le point n’est pas de faire disparaître l’information. Le point est de retirer au backlog ce coté puits sans fond.
Un backlog n’est pas une stratégie produit. Ce n’est pas une vision. Ce n’est pas une roadmap. Ce n’est pas un plan produit. Ce n’est pas une compréhension client. Ce n’est pas une architecture de décision. C’est un outil de travail opérationnel à horizon court terme. Et comme tout outil, il doit rester au service d’un système plus large : vision produit, stratégie business, objectifs, feedback utilisateurs, contraintes techniques, trajectoire d’architecture, capacité réelle des équipes, arbitrages économiques.
Quand le backlog contient tout, il finit par remplacer ces conversations. Et c’est là que ça devient pernicieux. On ne discute plus de stratégie, on discute de l’ordre des tickets. On ne discute plus de valeur, on discute d’effort. On ne discute plus de problèmes, on discute de demandes. On ne discute plus de choix, on discute de capacité.
C’est précisément là que le backlog devient dangereux. Non parce qu’il existe, mais parce qu’il absorbe des conversations qu’il ne devrait jamais remplacer.
Alors comment on en arrive là? La fausse sécurité de l’accumulation
Les organisations aiment conserver. Conserver ça rassure.
Un backlog plein donne le sentiment que rien n’est perdu, qu’on garde toutes les options ouvertes, qu’on pourra revenir plus tard, qu’on respecte les demandes, qu’on a une vision exhaustive du travail potentiel. Mais cette sécurité est largement illusoire, et pour trois raisons.
D’abord, l’information se dégrade. Une user story écrite il y a six mois, sans contexte vivant, sans conversation associée, sans sponsor clair, sans hypothèse explicite, perd vite sa valeur. Le ticket reste ; la compréhension, elle, s’est évaporée.
“Backlog Items Age Like Milk, Not Wine” David Pereira novembre 2022
Ensuite, les besoins changent. Le marché bouge, les clients évoluent, l’entreprise change de priorité, les contraintes techniques se transforment, les équipes se réorganisent. Ce qui était pertinent hier ne l’est pas forcément aujourd’hui.
Enfin, et c’est le plus important, tout conserver empêche de créer de l’espace. Or un système Produit a besoin d’espace pour apprendre : pour intégrer du feedback, saisir des opportunités émergentes, remettre en cause ses propres hypothèses, réallouer l’attention vers ce qui compte vraiment. Un backlog saturé donne une sensation de contrôle, mais il diminue la liberté réelle de l’organisation.
L’IA risque probablement d’aggraver le problème
Le sujet devient encore plus critique avec l’IA, et je pèse mes mots.
Aujourd’hui, il est trivial de générer des user stories propres, bien formulées, complètes en apparence. On demande à un modèle de transformer une vision en epics, des epics en features, des features en user stories, puis des user stories en critères d’acceptation. Sur le papier, c’est impressionnant.
Sauf que ça peut aussi devenir une machine à produire du backlog sans compréhension.
Le problème des user stories générées par IA, ce n’est pas qu’elles seraient mauvaises. C’est qu’elles peuvent être syntaxiquement parfaites tout en étant stratégiquement vides, et en plus comme elles sont produites rapidement et à faible coût, elles sont générées au kilomètres sans vraiement être (re)lues.
Or, une bonne user story n’est pas qu’une phrase au bon format. C’est la trace d’une conversation (souvenez vous mes 3C : Card, Conversation, Confirmation) . D’un problème compris. D’un besoin validé. D’un arbitrage. D’une intention produit.
Si l’IA génère l’epic, puis la story, puis les tests , puis le code mais qu’aucun humain n’a confronté l’idée à un utilisateur, à une stratégie, à une contrainte business ou à un signal de marché : j’ai peur que l’on obtienne un théâtre de productivité et non cette efficience tant désirée. Tout semble avancer. Tout semble structuré. Tout semble professionnel. Et le système livre une fonctionnalité que personne n’a vraiment demandée, comprise ou validée.
À la fin, l’organisation produit quelque chose qui a l’air cohérent dans l’outil, mais qui n’a jamais rencontré la réalité.
L’IA ne supprime donc pas le besoin de discipline produit. Elle l’amplifie. Plus il devient facile de produire des tickets, plus il devient vital d’être exigeant sur ce qui mérite d’entrer dans le backlog.
Les Product Owner ne peuvent pas porter ça seul-es
Avant même de parler de purge, il faut regarder qui tient les manettes. Parce qu’on ne peut pas demander à quelqu’un de nettoyer un système dont il ne contrôle pas les entrées. Dans beaucoup d’organisations, le PO est censé être responsable du backlog, mais il n’a ni l’autorité réelle, ni l’accès stratégique, ni la capacité de décision qui devraient aller avec.
On lui demande d’ordonner les demandes, mais il ne décide pas vraiment des objectifs. On lui demande de prioriser, mais les stakeholders contournent ses arbitrages dès que ça les arrange. On lui demande d’être owner, alors qu’on le traite comme un gestionnaire de flux, un secrétaire de comités, un traducteur de besoins métier en tickets.
C’est une contradiction structurelle. Et elle est rarement de son fait.
Un backlog sain ne dépend pas seulement d’un bon PO. Il dépend d’un système de responsabilité produit clair :
- Qui est responsable de la valeur créée par la solution ?
- Qui est responsable de la valeur livrée par l’équipe ?
- Qui arbitre entre objectifs business, contraintes techniques, besoins utilisateurs et capacité disponible ?
- Qui peut dire non ?
- Qui peut décider qu’un sujet sort du backlog ?
- Qui assume les conséquences de ces choix ?
Tant que ces questions restent floues, le backlog restera un espace de tension, et le PO continuera d’absorber tout ce que l’organisation ne sait pas arbitrer ailleurs.
Nettoyer son backlog sans répondre à ces questions, c’est vider une baignoire sans fermer le robinet.
Nettoyer le backlog, c’est donc nettoyer le système de décision
C’est pour ça que la vraie valeur d’une purge n’est pas opérationnelle. Elle est systémique.
Une purge sérieuse oblige à regarder comment les demandes entrent dans le système. À clarifier les critères d’entrée. À expliciter les règles de suppression. À séparer les idées brutes des sujets prêts à être travaillés. À distinguer une opportunité d’une demande, une hypothèse d’un engagement, une intention stratégique d’un ticket d’exécution.
Un backlog sain devrait avoir des règles visibles. Par exemple :
- un item sans responsable clair peut être supprimé ;
- un item dont plus personne ne comprend le « pourquoi » peut être supprimé ;
- un item non relié à un objectif ou à un problème actuel doit être réinterrogé ;
- une dette technique qui ne se manifeste jamais dans la réalité opérationnelle doit être requalifiée ;
- une demande stakeholder sans clarification de valeur ne devrait pas entrer directement dans le backlog d’équipe.
Ces règles peuvent sembler dures. Elles sont surtout nécessaires. Car sans règles, le backlog redevient une zone ouverte où chacun dépose ce qu’il veut et où l’équipe paie le coût de la confusion.
Parfois, « Now, Next, Later » suffit
Petite digression méthodo, parce que je vois souvent l’inverse sur le terrain : on surcomplexifie la priorisation. On cherche le framework parfait. On ajoute des scores. On pondère la valeur, l’effort, le risque, la confiance, l’urgence, le coût du délai. RICE, WSJF, MoSCoW, Eisenhower…
Ces approches sont utiles, surtout dans des environnements complexes ou à fort enjeu économique. Je ne dis pas le contraire. Elles peuvent aussi devenir une façon sophistiquée d’éviter une conversation simple :
- Qu’est-ce qui compte maintenant ?
- Qu’est-ce qui vient ensuite ?
- Qu’est-ce qui est pour plus tard ?
Le modèle « Now, Next, Later » a une vertu rare : tout le monde le comprend. Il force à distinguer l’attention immédiate, les sujets proches, et le reste. Et surtout il rend visible une vérité souvent oubliée : la colonne Later n’est pas un engagement. C’est une zone d’incertitude. Ce qui s’y trouve doit être régulièrement réinterrogé. Certains sujets remonteront, d’autres disparaîtront. Et c’est très bien comme ça.
Aucun framework ne remplacera jamais la décision, d’ailleurs. Beaucoup d’organisations ne manquent pas de méthodes de priorisation. Elles manquent de courage dans l’arbitrage. Tant que personne n’assume de dire « non », « pas maintenant », « ce n’est plus prioritaire », « cette demande ne correspond plus à notre stratégie », le backlog continuera de grossir, quel que soit le tableau Excel qu’on plaque dessus.
Ce que « delete your backlog » veut vraiment dire
Pris au pied de la lettre, « delete your backlog » est une provocation. Pris au sérieux, c’est une invitation à changer de rapport au backlog.
Ça ne veut pas dire que toutes les équipes doivent tout supprimer demain matin. Ni que la mémoire produit ne compte pas. Ni que les idées anciennes sont inutiles. Ni que la dette technique doit être ignorée. Ni que les stakeholders n’ont plus le droit de formuler des demandes. Ne me faites pas dire ce que je ne pense pas.
Ça veut dire autre chose :
- que le backlog ne doit pas devenir une décharge organisationnelle ;
- que conserver n’est pas prioriser ;
- qu’un ticket sans contexte vivant ne vaut pas grand-chose ;
- qu’une idée importante doit pouvoir survivre autrement que par son existence dans Jira ;
- que la stratégie produit doit vivre ailleurs que dans une liste de tickets ;
- qu’une organisation produit mature doit être capable de supprimer, pas seulement d’ajouter.
Et surtout, que le backlog doit redevenir ce qu’il n’aurait jamais dû cesser d’être : un outil au service du flux de valeur, un outil trés concret support à la conception, pas un substitut à la décision.
Un petit test?
On peut presque en faire un test. Ouvrez votre backlog, et posez-vous honnêtement la question :
- Combien d’items sont réellement compris par l’équipe ?
- Combien sont reliés à un objectif actuel ?
- Combien ont un propriétaire clair ?
- Combien reposent sur un signal utilisateur ou business récent ?
- Combien seraient recréés spontanément si vous les supprimiez aujourd’hui ?
- Combien existent seulement parce que personne n’a osé les retirer ?
Les réponses en disent long. Pas seulement sur la qualité de votre backlog, sur votre manière de faire du produit. Sur votre capacité à décider. Sur votre relation aux stakeholders. Sur votre courage à prioriser. Sur votre compréhension de la valeur.
Un bon backlog n’est pas un backlog exhaustif. C’est un backlog vivant, lisible, utile, aligné, régulièrement challengé. Un backlog qui aide l’équipe à créer de la valeur, plutôt qu’à gérer les fantômes des décisions passées.
Alors oui, supprimer son backlog est sans doute trop radical pour la plupart des organisations. Mais se demander ce qui se passerait si on le faisait reste un excellent exercice. Parce que si l’idée même vous terrifie, ce n’est peut-être pas parce que tout ce qu’il contient est indispensable.
C’est peut-être parce qu’il porte, à lui seul, une partie de la stratégie, de la mémoire, des arbitrages et des conflits que votre organisation n’a jamais vraiment structurés ailleurs.
Et dans ce cas, le problème n’est pas votre backlog. C’est votre système produit
