Un incrément produit est la somme des éléments du backlog terminés durant un sprint, ajoutés à ceux de tous les sprints précédents. Il doit être utilisable et conforme à la Definition of Done.
Le mot « terminé » porte ici un sens strict. Un élément développé mais non testé, ou testé mais non intégré, ne fait pas partie de l’incrément. Cette exigence évite l’accumulation d’un travail apparemment achevé qui reste en réalité à finir, et qui ressurgit toujours au pire moment.
La Definition of Done, contrat de qualité de l’incrément
La Definition of Done énumère les critères qu’un élément doit satisfaire pour être considéré comme terminé : code relu, tests automatisés passants, documentation à jour, déploiement effectué sur l’environnement de recette. Elle est partagée par toute l’équipe et ne se négocie pas élément par élément.
Une Definition of Done floue ou seulement implicite produit toujours le même symptôme : un travail déclaré fini en revue de sprint qui revient en correction deux sprints plus tard. La formaliser, même sommairement sur un simple document partagé, est l’une des actions les plus rentables pour une équipe qui débute.
Livrable ne veut pas dire livré
Un incrément doit être potentiellement livrable, ce qui ne signifie pas qu’il sera mis en production. La décision de livrer appartient au Product Owner et dépend de considérations commerciales, réglementaires ou calendaires étrangères à l’équipe de développement.
L’important est que la décision reste possible à tout moment, sans travaux préalables cachés. Le Scrum Guide précise d’ailleurs que plusieurs incréments peuvent être produits au cours d’un même sprint et que la revue de sprint n’est pas une porte de validation obligatoire avant mise en production.
Enfin, l’incrément est cumulatif et c’est ce qui le distingue d’une simple livraison. Il n’est pas le résultat du dernier sprint pris isolément, mais l’ensemble du produit tel qu’il existe à cet instant, incluant tout ce qui a été construit auparavant. Cette définition impose de vérifier à chaque cycle que les fonctionnalités précédentes fonctionnent toujours — ce qui explique pourquoi l’automatisation des tests de non-régression devient rapidement indispensable dès que le produit gagne en volume.