Backlog qui grossit : la règle entrées/sorties

Le backlog qui grossit : trois symptômes qui ne trompent pas

Vous ouvrez votre board le lundi matin et la première colonne compte 400 cartes. Vous scrollez. Vous fermez. Vous en ajoutez une de plus. C'est le signe que votre backlog n'est plus un outil de priorisation, mais un journal.

Trois symptômes reviennent :

• Le rituel de planning qui s'éternise. Chaque sprint, on reparcourt la liste, on argumente, on choisit selon qui a parlé le plus fort cette semaine.
• Les vieux items qui ne meurent jamais. Une idée déposée il y a huit mois reste « en attente » sans que personne ne sache pourquoi.
• Les comparaisons absurdes. On met côte à côte « migrer l'authentification » et « changer la couleur du bouton d'onboarding » comme s'il s'agissait du même type de décision.

Ces trois symptômes viennent d'une même cause structurelle : un backlog plat. Quand tout est au même niveau, chaque conversation de priorité repart de zéro.

Séparer les altitudes avant de mesurer quoi que ce soit

Le modèle des flight levels décrit trois altitudes de décision : stratégique (où investir), coordination (comment le travail circule entre les équipes) et opérationnelle (comment une équipe exécute). Chaque altitude a son rythme, ses décideurs et sa définition de « terminé ».

Quand une organisation gère tout à une seule altitude, les décisions stratégiques se retrouvent noyées dans des débats opérationnels, et des ajustements tactiques prennent la même solennité qu'un pari de plateforme. Rien n'avance au bon rythme.

Concrètement, avant de compter les entrées et les sorties, faites le tri :

• Stratégique : « Faut-il remplacer notre système de paiement ? » — décision trimestrielle, peu de gens dans la pièce.
• Coordination : « Quelle initiative traite quel problème client ce trimestre ? » — revue mensuelle.
• Opérationnelle : « Quelle user story passe dans ce sprint ? » — décision hebdomadaire de l'équipe.

Un item qui n'appartient pas à l'altitude de la réunion en cours n'a rien à y faire. Ce simple filtre élimine la moitié des débats stériles.

Pourquoi un backlog saturé ralentit de façon exponentielle

La théorie des files d'attente appliquée au développement produit donne un résultat contre-intuitif : quand une ressource approche 100 % d'utilisation, la file grandit de façon exponentielle, pas linéaire. La formule M/M/1 s'écrit attente = utilisation / (1 − utilisation). À 50 % d'utilisation, l'attente vaut 1×. À 80 %, 4×. À 90 %, 9×. À 95 %, 19×.

Autrement dit : plus vous serrez votre capacité, plus la file explose. Vous ne rattraperez pas une exponentielle en travaillant plus.

La loi de Little donne l'autre moitié du tableau : temps de cycle = travail en cours / débit. Un projet open source documenté avait environ 200 pull requests ouvertes et fusionnait 20 à 35 PR par mois : le temps de cycle moyen ressortait à environ 6,7 mois. Ce n'est pas un backlog temporaire, c'est le comportement normal du système à cette charge.

Le même raisonnement s'applique à votre backlog : si vous avez 180 items ouverts et que vous en livrez 6 par sprint, votre temps de traversée moyen est de 30 sprints. Ce chiffre, affiché en réunion, change souvent la conversation plus efficacement qu'un débat d'opinions.

Le tableau de suivi entrées/sorties, en cinq colonnes

Vous n'avez pas besoin d'un outil sophistiqué. Un tableur partagé suffit, à condition de le remplir chaque semaine, à la même heure, par la même personne.

Cinq colonnes :

1. Semaine — la date du relevé.
2. Entrées — nombre d'items ajoutés au backlog cette semaine.
3. Sorties livrées — items passés en « terminé » et effectivement utilisables.
4. Sorties abandonnées — items explicitement fermés sans être livrés.
5. Total ouvert — le solde en fin de semaine.

Deux ratios se calculent tout seuls :

• Ratio entrées/sorties = entrées ÷ (livrées + abandonnées). Au-dessus de 1, le backlog grossit. En dessous de 1, il se résorbe.
• Âge médian des items ouverts — la moitié des items ouverts sont plus vieux que ce nombre de semaines. S'il dépasse 12, votre backlog est un archivage, pas un plan.

Le chiffre qui déclenche une action, c'est le ratio entrées/sorties sur quatre semaines consécutives. S'il reste au-dessus de 1,2, vous avez un problème de plafond, pas de productivité.

Une plateforme comme Ever Earlier affiche un journal d'activité par carte et par colonne : vous pouvez reconstituer ces chiffres sans tenir un tableur parallèle, en filtrant les cartes créées et terminées sur la période.

Fixer un plafond par sprint (et le tenir)

Un plafond d'entrées n'est pas une limite à l'imagination. C'est une limite au travail accepté. La distinction est essentielle quand vous l'annoncez.

Trois règles simples :

• Plafond d'entrées : par exemple 5 nouveaux items par sprint et par équipe. Au-delà, l'item va dans une liste « à qualifier » qui n'est pas le backlog actif.
• Seuil de sortie obligatoire : tout item ouvert depuis plus de 8 sprints est soit planifié dans les 2 sprints suivants, soit fermé. Pas de zone grise.
• Budget de nettoyage : 10 à 15 % de la capacité du sprint réservée au grooming et à la fermeture d'items obsolètes. Ce n'est pas du temps perdu, c'est ce qui empêche la file d'exploser.

Le plafond doit être visible. Sur un board Kanban, une colonne « À qualifier » avec un compteur suffit. Quand elle est pleine, on ne discute plus de l'ajout, on discute de ce qu'on retire.

Attention à ne pas confondre plafond d'entrées et plafond de travail en cours. Le premier limite ce qui entre dans le backlog ; le second limite ce qui est en cours d'exécution. Les deux sont utiles, mais ils ne se substituent pas.

Dire non sans conflit : quatre scripts à réutiliser

La plupart des conflits autour du backlog ne viennent pas d'un désaccord sur la valeur de l'idée, mais d'un malentendu sur ce que « ajouter au backlog » signifie. Recadrez la conversation sur le coût, pas sur le mérite.

Script 1 — Quand un dirigeant ajoute une idée en réunion

« Je note l'idée, elle est légitime. Pour la mettre dans le sprint en cours, il faut retirer autre chose : voici les trois items qui sont au même niveau de priorité. Lequel décale-t-on ? »

Vous ne refusez pas. Vous rendez le coût visible.

Script 2 — Quand une partie prenante insiste sur l'urgence

« D'accord sur l'urgence. Notre plafond d'entrées de ce sprint est atteint. Deux options : on la traite au sprint suivant en priorité haute, ou on décale l'item X qui était prévu. Vous préférez laquelle ? »

Script 3 — Quand un item dort depuis des mois

« Cet item est ouvert depuis six mois sans avoir été planifié. Est-ce qu'il est encore d'actualité ? Si oui, on le planifie dans les deux prochains sprints. Sinon, on le ferme et on garde une note pour l'historique. »

Script 4 — Quand on vous reproche de « dire non à tout »

« On ne dit pas non aux idées, on dit non à l'empilement. Chaque item qu'on ajoute sans en retirer un autre allonge le délai de livraison de tous les autres. Voici le chiffre de la semaine. »

Ces quatre scripts fonctionnent parce qu'ils déplacent la décision : ce n'est plus « ton idée contre la mienne », c'est « quel item sort pour que celui-ci entre ».

Et le refactoring ? Il ne va pas au backlog

Question classique : faut-il créer des user stories de refactoring dans le backlog ? La réponse, formulée il y a longtemps par Ron Jeffries, reste valable : c'est une mauvaise idée.

Un gros chantier de nettoyage est difficile à vendre, et quand il est vendu, il rapporte moins que prévu après un long délai. La bonne approche est incrémentale : quand vous construisez la prochaine fonctionnalité, au lieu de contourner les zones problématiques, vous nettoyez le chemin que vous traversez. Vous ignorez le code que vous n'avez pas à toucher.

Parfois la fonctionnalité prend un peu plus de temps. Souvent non, parce que le nettoyage aide dès la première feature qui passe par là. Et la fois suivante, le bénéfice est immédiat.

Conséquence pratique pour votre backlog : ne créez pas d'items « dette technique » génériques. Ajoutez plutôt un critère d'acceptation à la user story en cours, du type « le module X est couvert par des tests avant la mise en production ». Le nettoyage devient une propriété de la feature, pas un chantier séparé.

Le rituel hebdomadaire : 30 minutes, cinq questions

Un tableau de suivi ne sert à rien s'il n'est pas lu. Bloquez 30 minutes par semaine, en dehors des cérémonies agiles classiques, avec la personne qui tient le backlog.

Cinq questions, dans cet ordre :

1. Combien d'items sont entrés cette semaine ? Par qui ?
2. Combien sont sortis, livrés ou abandonnés ?
3. Quel est le ratio entrées/sorties sur les quatre dernières semaines ?
4. Quels items ouverts ont plus de 8 sprints ? Que fait-on d'eux ?
5. Le plafond d'entrées du prochain sprint est-il déjà atteint ?

Si la réponse à la question 5 est oui, la réunion de planning suivante commence par une décision de retrait, pas par un ajout. C'est ce qui distingue un backlog vivant d'un cimetière avec une barre de recherche.

Sur Ever Earlier, vous pouvez filtrer les cartes par date de création et par statut dans le journal d'activité, puis exporter la vue pour la réunion. L'agent IA qui génère des user stories à partir d'epics reste utile, à condition de ne pas l'utiliser pour remplir le backlog plus vite qu'on ne le vide.