Ca commence toujours pareil.
Le ticket arrive en sprint planning. Quelqu’un dit « c’est rapide, deux jours max ». Tout le monde hoche la tête. Personne ne pose de question. Le ticket entre dans le sprint avec une estimation de 3 points et une énergie collective de « on règle ça vite fait ».
Trois semaines plus tard, le ticket est toujours là.
« Quick win » est la plus belle promesse du développement produit. Et la plus mensongère.
Pas par mauvaise foi. Par optimisme. Par envie de bien faire. Par cette petite voix qui dit que cette fois, ce sera simple, que le code est propre à cet endroit, que personne n’a touché ce module depuis longtemps donc forcément ça doit être stable.
Spoiler : le code n’est jamais propre à cet endroit. Quelqu’un a toujours touché ce module. Et « ça fait longtemps que personne n’y est allé » est exactement la raison pour laquelle ça va prendre du temps.
L’estimation, c’est pas de la prédiction. C’est de la narration.
Quand un développeur dit « deux jours », il raconte une histoire. L’histoire d’un monde idéal où les specs sont claires, les dépendances connues, les tests écrits et le reste du sprint vide.
Ce monde n’existe pas.
Le vrai problème, c’est que tout le monde le sait. Le dev qui estime. Le PO qui valide. Le Scrum Master qui note. Et pourtant, personne ne dit rien. Parce que remettre en question une estimation en sprint planning, c’est socialement inconfortable. Ca ralentit la réunion. Ca donne l’impression de bloquer l’équipe.
Alors on note 3 points et on verra bien.
On voit bien. Trois sprints plus tard.
Voilà ce qui se passe vraiment sur un « quick win » qui dérape. Premier sprint : la tâche commence, on découvre une dépendance non documentée. On bloque. On reporte. Deuxième sprint : reprise, mais un bug critique ailleurs mobilise les devs. Le ticket attend. Troisième sprint : on finit, mais les tests révèlent un effet de bord. Correction, re-recette, merge tardif.
Neuf semaines pour deux jours estimés. La vélocité s’en prend un coup. Et personne ne comprend vraiment pourquoi le sprint n’a pas été tenu.
La dette technique, c’est des intérêts sur chaque quick win mal estimé.
Chaque raccourci pris pour livrer vite devient une contrainte pour le ticket suivant. Et le suivant. Jusqu’au moment où tout « quick win » se transforme automatiquement en investigation, parce que le code est tellement chargé d’histoires non documentées qu’aucune modification ne peut vraiment être rapide.
C’est ça la dette technique. Pas un concept abstrait de conférence tech. Des tickets à 3 points qui finissent à 13.
Et si on supprimait « quick win » de nos backlogs ?
Pas parce que l’intention est mauvaise. Parce que le mot crée une attente qui contamine l’estimation avant même que la conversation commence.
Un spike d’investigation avant d’estimer. Une honnêteté collective sur ce qu’on ne sait pas encore. Et l’acceptation que vouloir que quelque chose soit rapide ne le rend pas rapide.
Votre prochain sprint planning mérite cette conversation là.
Alors, vous le bannissez ou vous le gardez ?