Votre backlog ne priorise pas. Il accumule.

Imaginez le sprint planning classique : 400 tickets dans Jira, tout le monde défile les écrans en silence, personne ne sait vraiment par où commencer. Mais personne ne le dit non plus. On prend les 3 ou 4 tickets du dessus, on lance le sprint, et on fait comme si le reste allait se régler tout seul. Quand avez-vous relu le ticket tout en bas de votre backlog ? Ce n'est pas un problème d'organisation. C'est un problème de courage produit.

Ce que cache un long backlog

Un backlog de 400 tickets, ça impressionne. Ça donne le sentiment d'avoir un plan. En réalité, la plupart de ces tickets n'ont aucune chance d'être développés un jour.

Les fonctionnalités que personne n'a demandées deux fois. Si quelqu'un avait vraiment besoin de cette feature, il en aurait reparlé. Un utilisateur qui souffre vraiment d'un manque revient, il relance, il insiste. Un ticket silencieux depuis 4 mois n'attendait pas votre prochain sprint, il attendait d'être archivé.

Les bugs oubliés par tout le monde sauf celui qui les a créés. Un bug non reproduit depuis 6 mois n'existe plus en pratique. L'utilisateur a trouvé un contournement, est passé à autre chose, ou n'utilise plus la fonctionnalité. Le ticket reste là, il encombre, il pollue les estimations.

Les idées d'il y a 8 mois qui ne font plus sens. Le marché a bougé, l'ICP a changé, les priorités ont évolué. Le ticket, lui, n'a pas bougé d'un pixel. Il documente ce qu'on pensait à l'époque, pas ce dont on a besoin maintenant.

J'ai audité le backlog d'une startup en série A il y a quelques mois : 340 tickets au total, 280 n'avaient pas été touchés depuis plus de 4 mois. On a organisé une session de 2 heures avec le fondateur et la PM. On a archivé 280 tickets. Personne ne s'en est plaint. Pas une seule demande de récupération dans les semaines qui ont suivi.

Le backlog est la somme des décisions que personne n'a eu le courage de prendre. Chaque ticket qui traîne est un choix qu'on a évité de faire.

Pourquoi on n'ose pas le vider

La peur de perdre une bonne idée est le premier argument qu'on entend. C'est aussi le plus facile à démolir. Les bonnes idées reviennent d'elles-mêmes. Si une idée a vraiment de la valeur, quelqu'un en reparlera. Archiver un ticket ne fait pas disparaître le problème qu'il décrit. Il fait juste disparaître le ticket.

Un backlog plein, c'est aussi rassurant. Ça donne l'illusion d'avoir un plan, d'avoir pensé à tout. Le problème, c'est que ce plan ne tient pas face à la réalité de ce qu'on construit vraiment. Un backlog court oblige à admettre ce qu'on ne fera pas. C'est inconfortable, et la plupart des équipes préfèrent éviter ça.

Et puis il y a la pression politique. On n'ose pas supprimer le ticket que le commercial a ajouté après une démo client. On n'ose pas dire à l'investisseur que sa suggestion est enterrée depuis 6 mois. Alors on garde. On déprioritise sans jamais archiver. Le backlog grossit par peur sociale autant que par manque de méthode.

La méthode : brûler le backlog tous les 3 mois

Voilà ce que je fais avec les équipes que j'accompagne. Ce n'est pas sorti d'un manuel agile, c'est juste ce qui fonctionne.

Le principe de départ : tout ticket non touché depuis 90 jours est mort. Pas "à faible priorité", pas "à revoir plus tard". Mort. Une règle floue ne change aucun comportement.

D'abord, on exporte tout le backlog. Titre, date de création, date de dernière modification, dernier commentaire. Un tableur suffit. L'intérêt, c'est d'avoir une vue brute sans le biais de l'outil qui met toujours les mêmes tickets sous les yeux.

Ensuite, le filtre : tout ce qui n'a pas été touché en 90 jours part en archive. On n'en discute pas ticket par ticket, ça prendrait une journée et ça deviendrait une négociation sans fin. On applique la règle et on passe. L'exception existe mais elle doit se justifier en 30 secondes : un signal utilisateur récent, concret. Pas une intuition.

Enfin, on reconstruit à partir des vrais signaux. On garde les tickets actifs des 3 derniers sprints et les demandes utilisateurs répétées des 4 dernières semaines. On archive tout le reste. On supprime les doublons et les tickets "un jour peut-être" sans champion désigné.

Pour structurer ce qui reste, j'utilise une roadmap Now/Next/Later, j'en parle en détail dans cet article sur la planification agile en startup.

Un backlog sain tient sur un seul écran sans scroller. Si vous devez faire défiler la page pour voir la fin de votre backlog actif, vous avez une liste de souhaits, pas un backlog.

La première session prend 2 à 3 heures. Les suivantes, 45 minutes. Faites-en un rituel trimestriel, au même titre que la rétrospective. C'est de la maintenance, comme une rétro. On le fait régulièrement, pas quand c'est déjà le chaos.

Ce qu'il faut retenir

• Un backlog long n'est pas un signe de richesse produit. C'est un signe de manque de décision.
• Tout ticket non touché depuis 90 jours est probablement mort. Archivez-le sans culpabilité.
• Si c'est vraiment important, ça reviendra. Si ça ne revient pas, c'était du bruit.

Questions fréquentes

Et si on archive un ticket qui s'avère important plus tard ?

L'archive n'est pas la corbeille. Si le besoin réapparaît, vous retrouvez le ticket, et cette fois vous avez un vrai signal utilisateur pour le justifier. Dans les équipes avec qui j'ai fait cet exercice, le taux de récupération de tickets archivés est inférieur à 5 %.

Comment convaincre l'équipe de vider le backlog ?

Ne cherchez pas à convaincre par l'argument. Faites-le ensemble, en session courte, en appliquant la règle des 90 jours sans débat au cas par cas. La plupart des équipes ressentent un vrai soulagement une fois l'exercice terminé. Un backlog allégé rend les sprints plus clairs et les plannings moins anxiogènes.

Combien de tickets un backlog sain devrait-il contenir ?

Pas de nombre magique. La règle pratique : l'équipe doit pouvoir lire le backlog actif en entier et se souvenir de ce qu'il contient. En early-stage avec une équipe de 3 à 5 personnes, 20 à 40 tickets actifs c'est déjà généreux. Au-delà, soit vous avez trop d'entrées, soit votre vision n'est pas assez claire pour couper.

Conclusion

La règle que j'applique systématiquement : si c'est vraiment important, ça reviendra. Si ça ne revient pas, c'était du bruit. Un ticket archivé qui ne resurgit jamais vous confirme que vous avez pris la bonne décision.

Combien de tickets avez-vous dans votre backlog en ce moment ? Si la réponse vous met mal à l'aise, ou si vous ne savez même pas sans aller vérifier, c'est peut-être le bon moment pour en parler. Réservez 30 minutes, c'est suffisant pour clarifier où vous en êtes et par où commencer.