Le sprint de stabilisation est un aveu, pas un remède
De temps à autre, une équipe annonce qu'il lui faut un « sprint de stabilisation » — un Sprint réservé à corriger des bogues, intégrer des composants, terminer les tests et, de façon générale, rendre le produit livrable. Cela semble responsable. C'est en réalité un aveu. Un Sprint de stabilisation, c'est l'équipe qui vous dit, à voix haute, que le travail qu'elle a déclaré « terminé » lors des Sprints précédents ne l'était pas vraiment. Dans un cadre dont toute la prémisse est un Incrément utilisable et livrable à la fin de chaque Sprint, cela mérite qu'on s'y arrête.
Le Guide Scrum est clair sur ce point : chaque Sprint doit produire un Incrément qui satisfait à la Définition de « Terminé », et cette définition est la description partagée et formelle, par l'équipe, de la qualité requise pour que le produit soit livrable. Si un Incrément n'y satisfait pas, il ne peut être mis en production — et, surtout, il ne devrait pas être présenté comme achevé. Rien ne prévoit qu'un Sprint ultérieur rende rétroactivement acceptable un travail antérieur. La stabilisation n'est qu'une Définition de « Terminé » différée, reconditionnée en plan.
Ce qui est sain
Dans une Équipe Scrum saine, le « terminé » ne se négocie pas élément par élément, et la qualité s'intègre au fil du travail.
Chaque élément du Backlog Produit déclaré terminé satisfait déjà à la même Définition de « Terminé » — testé, intégré, documenté comme la DoD l'exige.
Tests, intégration et revue se font à l'intérieur du Sprint, en parallèle de la construction, et non empilés pour plus tard.
L'Incrément présenté à la Revue de Sprint est réellement livrable ; la décision de livrer est une décision d'affaires, pas une course technique de dernière minute.
La dette technique est visible dans le Backlog Produit et remboursée délibérément, sans qu'on la laisse s'accumuler en silence jusqu'à exiger un Sprint dédié.
Si l'équipe ne peut achever un élément selon la Définition de « Terminé », il reste non terminé et retourne au Backlog Produit — on ne le laisse pas passer.
Ce qui ne l'est pas
Le patron de stabilisation a une forme reconnaissable, et il vient rarement seul.
Une Définition de « Terminé » faible ou facultative. On marque des éléments comme achevés dès que le code compile et que la démo fonctionne, en reléguant tests et intégration au problème ultérieur de quelqu'un d'autre. La DoD existe sur papier mais pas en pratique.
Une vélocité flatteuse. Les Sprints de fonctionnalités paraissent rapides et productifs justement parce qu'ils sautent le travail de finition ; puis un Sprint de stabilisation absorbe la facture. La vélocité rapportée n'a jamais été réelle.
L'intégration big-bang. Les composants sont construits isolément et raccordés seulement à la fin, si bien que le Sprint de stabilisation devient la première occasion de découvrir si le système fonctionne vraiment.
Une date de livraison qui dicte la vérité. Comme la mise en production est fixée à une date ferme, la qualité devient la variable d'ajustement, et « on stabilisera après » devient l'échappatoire permanente.
Aucun de ces écueils n'est un problème d'outillage. C'est une équipe — souvent sous une réelle pression de calendrier, que les pénuries de main-d'œuvre de 2022 et les retours au bureau mouvants n'ont fait qu'aggraver — qui redéfinit en douce le « terminé » vers le bas et le paie d'un coup plus tard. Le Sprint de stabilisation, c'est là où atterrit enfin ce coût différé.
Traiter la cause, pas le symptôme
Le remède n'est pas de mieux planifier le Sprint de stabilisation. C'est de le rendre inutile. Renforcez la Définition de « Terminé » jusqu'à ce qu'elle signifie réellement livrable, puis exigez-la de chaque élément. Ramenez tests et intégration dans le Sprint, là où le travail est frais. Faites de la dette technique un élément visible et priorisé du Backlog Produit plutôt qu'un solde caché. Une fois que « terminé » signifie vraiment terminé, le Sprint spécial de stabilisation n'a plus rien à faire — et c'est précisément le but.
Si vos équipes de livraison constatent sans cesse qu'il leur faut un sprint pour « finir de finir », le service-conseil en livraison de programmes et de projets de XNM peut vous aider à resserrer la Définition de « Terminé » et à intégrer la qualité là où elle doit l'être.