Ton équipe paie deux fois ce qu'elle livre"
Resserrer la DoD n'empêche pas les bugs de naître par magie...
Une équipe que j'accompagnais "livrait" des bugs à chaque sprint. Entre 30 et 50 % des items terminés revenaient buggués au sprint suivant.
Mon premier réflexe : renforcer la DoD. On l'a conclu en rétro, sans regarder un seul chiffre, et le QA s'est resserré.
Sauf qu'au final plus les bugs remontaient, et moins de travail sortait. Nos dates devenaient encore moins bonnes.
Un défaut, c'est une date qui recule
Chaque bug qui revient, c'est de la capacité qui sert à refaire au lieu d'avancer. Le PO voit sa date glisser, le client voit revenir sur la table ce qu'il croyait réglé. Et l'équipe refait ce qu'elle a déjà fait avant (qui aime ça en fait ?).
Donc la qualité, c'est aussi l'affaire du SM : rendre visible à l'équipe ce que ça lui coûte. Sans chiffre, devant ton PO, "l'équipe passe son temps à corriger" sonne un peu comme une excuse.
Le compte de reprise : 3 sprints, 2 colonnes
Ouvre tes 3 derniers sprints. Exemple (chiffres fictifs) :
| Sprint | Bugs/Hotfix d'items finis | Jours à refaire (reprise) |
|---|---|---|
| 1 | 5 | 14 |
| 2 | 4 | 12 |
| 3 | 6 | 16 |
Bug ou info manquante au départ ? Compte les deux, pas les urgences du sprint.
- Capacité : 7 personnes × 10 jours × 3 sprints = 210 jours.
- Jours de reprise : 14 + 12 + 16 = 42 jours. 42 ÷ 210 = un jour sur 5.
- Sur la date : si ton PO a prévu 8 sprints, (sans compter la reprise imprévue). À un jour sur 5, l'équipe avance à 80 % : 8 sprints ÷ 0,8 = 10 sprints. Environ 2 sprints de plus.
- Si la reprise tombe à un jour sur dix : 8 ÷ 0,9 ≈ 9 sprints. Un sprint récupéré !
Pour ton PO, un sprint de plus, c'est du budget à redemander.
La phrase pour ton PO : "Au rythme actuel, la reprise des bugs ajoute (x) sprints à ta date. Si on la divise par 2, on en récupère (y)."
C'est aussi ce chiffre qui le convainc parfois de mettre du temps sur la dette technique pour livrer plus vite ensuite.
Ce qu'on a trouvé quand on a enfin regardé
Mon équipe en avait marre : corriger un truc vieux de plusieurs semaines, c'est reprendre depuis le début tout le contexte oublié. On a cherché le point commun avec le lead technique, story par story. Puis il l'a vu : au cœur de chacune, une transformation de données, et presque toujours une info manquante avant de commencer. Pas codée, donc rattrapée des sprints plus tard par une autre équipe. Ou pire, par le client.
C'est là qu'on a mis l'effort sur le refinement : capturer les critères de test de la transformation de données avant d'écrire une ligne. On est passé à environ 10 % d'items qui revenaient par sprint.
Le lead l'a trouvé, pas moi ! Je l'aurais pas vu. Donc contacte ton équipe d'abord, pour arriver devant le PO avec son chiffre à elle...
Ton expérimentation cette semaine
- Avant vendredi, sors la première colonne seul (20 min). Selon ta relation avec ton PO, préviens-le en 1-1 : "On cherche d'où viennent les bugs, je te reviens avec le chiffre." Garde la boucle courte : vous visez le même objectif.
- Montre-la à l'équipe, avec ton lead technique. Estime les jours avec eux, puis une question : "Qu'est-ce que ces bugs ont en commun ?"
- Avant le planning, rencontrer le PO, avec le chiffre de l'équipe.
Le prochain trou à mesurer : tout ce qui est commencé et pas fini.
Ton dernier sprint, combien de jours ont servi à refaire ?
PS : Le Corpus Implicite ferme le 19 octobre. 90+ Scrum Masters ont déjà répondus. Ça prends 5min. Je donnerais des réponses lors de l'Agile Tour en novembre 2026.
