En gestion de projet agile et plus particulièrement en Scrum, il y a une notion indispensable mais que les équipes ont du mal à s'approprier : l'incrément.
Dans cet article, je vous explique précisément ce qu'est un incrément d'après le guide Scrum, et quelles sont les bonnes pratiques concernant vos incréments.
Qu'est-ce qu'un incrément Scrum ?
Définition d'un incrément agile
Un incrément est le résultat visible du travail accompli lors d'un sprint par l'équipe Scrum. C'est la somme de tous les éléments faits durant le sprint, qui permet de se rapprocher de la vision et de l'objectif du produit final. Il s'ajoute aux incréments précédents afin de former un produit.
L'incrément est le troisième artefact Scrum, après le Product backlog et le Sprint backlog. Il s'agit d'un résultat tangible, palpable, qui matérialise et rend visible le travail de l'équipe.
Un incrément est considéré comme tel dès lors que la définition de fini (definition of done) est respectée. Grossièrement, on peut considérer que dès qu'un item (user story) est fini, alors nous avons un incrément.
L'incrément de sprint est la somme de tous les éléments réalisés à 100% durant le sprint.
L'équipe ne s'engage jamais sur un incrément, mais plutôt sur la "definition of done". On considère ainsi la "definition of done" comme l'engagement de l'incrément.
Que dit le Scrum Guide sur l'incrément ?
Analysons ensemble le Scrum Guide 2020 version française pour voir ce qu'il nous raconte sur l'incrément :
- "Un incrément est une première étape concrète vers l'objectif de produit."
Un incrément est donc un bout de produit. C'est quelque chose de palpable, de concret. - "Chaque incrément s'ajouter à tous les incréments précédents."
Chaque incrément s'additionne avec les précédents afin de former un "super-incrément" : le produit à son état actuel. - "Chaque incrément fait l'objet d'une vérification approfondie, ce qui garantit que tous les incréments fonctionnent ensemble."
Pour qu'un travail soit considéré comme un incrément, il doit être vérifié et fini à 100%. La definition of done aide l'équipe en ce sens. - "Afin de fournir de la valeur, l'incrément doit être utilisable."
Autrement dit, il doit fonctionner techniquement, ne pas avoir de bugs, et l'utilisateur final doit être en capacité de pouvoir l'utiliser. - "Plusieurs incréments peuvent être créés durant un sprint."
Dès qu'une user story est considéré comme terminée, elle devient un incrément. La somme de ces incréments devient l'incrément de Sprint à la fin du sprint. - "La somme des incréments est présentée lors de la sprint review."
Tous les incréments du sprint (donc le travail réalisé à 100%) est présenté aux parties prenantes du projet lors de la réunion de sprint review. - "Un incrément peut être livré aux parties prenantes avant la fin du sprint."
Il est possible de livrer un incrément en cours de sprint afin de recueillir du feedback sans attendre la sprint review. - "Un travail qui ne remplirait pas les conditions de la Definition of Done ne peut pas être considéré comme un incrément."
La définition de fini indique ce qui caractérise un travail terminé. Un travail terminé à 99% ne peut pas être un incrément et donc ne peut pas être présenté aux parties prenantes.
Personnellement, je trouve que le Scrum Guide n'est pas suffisamment explicite sur la notion d'incrément. Il aurait gagné à mieux être formulé, ce qui participerait à lever le flou qui règne encore sur ce qu'est un incrément au sein des équipes.
Qu'est-ce que la "Definition of done" ?
La definition of done, ou définition de fini, décrit les caractéristiques de ce qu'est un travail terminé. Elle permet d'assurer un haut niveau de qualité du produit. Il s'agit généralement d'une liste de critères de validation, qui détermine si une user story est terminée ou non.
Elle crée de la transparence en permettant à chacun de comprendre le travail accompli dans le cadre de l’Incrément. C’est une approche agile cruciale pour la transparence et la qualité.
La definition of done est définie par l'équipe, et est suivie au quotidien lors des sprints. La notion de définition de fini peut évoluer dans le temps, notamment en fonction des retours faits en rétrospective.
Cette notion est particulièrement utile pour limiter la dette technique sur les produits (moins de bugs), et également pour réduire l'incertitude.
Un incrément est-il un engagement de l'équipe ?
L'incrément n'est en aucun cas un engagement de l'équipe Scrum. L'équipe ne s'engage pas à l'avance sur un nombre de fonctionnalités à livrer. Elle s'engage cependant sur la qualité de ce qui sera livré, grâce à la definition of done.
De la même manière, les items (ou user stories) ajoutés au sprint backlog ne sont pas un engagement de l'équipe. Ils 'agit d'une quantité de travail qu'ils pensent pouvoir réaliser dans le sprint, pas d'un engagement ferme et précis.
L'incrément n'est donc pas une promesse. C'est un fait. C'est le résultat concret du travail réalisé, qui satisfait à la définition de fini.
Peut-on livrer un incrément avant la fin du sprint ?
Le Scrum Guide nous dit très clairement qu'un "incrément peut être livré aux parties prenantes du projet avant la fin du sprint".
La plupart du temps, les équipes préfèrent tout de même attendre la sprint review afin de livrer des incréments aux parties prenantes.
Pour rappel, un incrément est un travail comme une user story qui est considéré comme terminé. Ceux-ci s'additionnent pour former l'incrément de sprint en fin de sprint.
Peut-on avoir plusieurs incréments durant un sprint ?
Un sprint doit avoir au minimum 1 incrément, mais il n'existe pas de limite supérieure. On peut donc avoir plusieurs incréments durant un sprint. Une user story est considérée comme un incrément dès lors qu'elle respecte la definition of done.
Tous ces incréments s'additionnent en fin de sprint afin de former ce qu'on appelle l'incrément de sprint.
Un sprint doit-il obligatoirement avoir un incrément ?
Un sprint doit avoir au minimum 1 incrément à fournir. Livrer un incrément, c'est livrer de la valeur aux parties prenantes. Cette notion de valeur est au cœur de l'agilité.
Par conséquent, ne pas livrer d'incrément au cours d'un sprint revient à dire qu'on n'a fourni aucune valeur. C'est un problème. L'équipe doit travailler sur ce point afin d'identifier ce qui s'est mal passé et le corriger.
Comment vérifier l'incrément et garantir sa fiabilité ?
Comment s'assurer qu'un incrément est un bon incrément de qualité ?
Le Scrum Guide nous dit ceci : "L'incrément doit être potentiellement livrable à chaque itération".
Mais qu'est-ce que ça veut dire concrètement ?
- L'incrément doit respecter la definition of done.
L'équipe Scrum a défini en amont ce qu'est pour eux un travail terminé. Elle se conforme alors à cette définition et vérifie pour chaque user story traitée qu'elle coche bien toutes les cases et qu'elle est bien finie à 100%. - L'incrément doit être fonctionnel.
Le travail livré doit fonctionner techniquement et s'intégrer avec les autres incréments du produit, sans créer de bugs. La definition of done doit donc comporter des batteries de tests à réaliser. - L'incrément doit être utilisable.
Un incrément de qualité doit être utilisable par l'utilisateur final. Il doit donc répondre à son besoin mais doit également être documenté.
Qui garantit la validité d'un incrément ?
Une user story devient un incrément lorsqu'elle passe tous les critères de validité et les tests décrits dans la definition of done.
En gestion de projet classique, on a le responsable qualité qui s'occupe de ça. Mais avec Scrum, qui à la charge de vérifier cela ?
C'est là la beauté de l'agilité. Le rôle de responsable qualité n'est pas attribué à une seule personne, mais est plutôt partagé par l'ensemble des membres de l'équipe Scrum.
C'est donc l'équipe toute entière qui est responsable de la qualité et de l'engagement de definition of done.
Comment présenter l'incrément aux parties prenantes ?
L'incrément de sprint (la somme des incréments du sprint) est présenté aux parties prenantes lors de la réunion de Sprint review.
On présente généralement lors de cet évènement une démonstration de l'incrément, sa documentation, etc...
On profite également de ce moment afin de recueillir du feedback sur l'incrément, afin de s'assurer qu'il répond bien aux attendes, et de voir comment on pourrait l'améliorer par la suite.
Toutefois, j'insiste sur un point important : présenter la fonctionnalité aux parties prenantes ne signifie pas qu'elle a été publiée publiquement. Un incrément peut être prêt mais intégrer la prochaine release dans plusieurs semaines.
