L’incrément, qu’est-ce que c’est ?
L’Incrément est le plus petit artéfact visible de la Scrum Team, aux yeux des personnes extérieures.
Un Increment est une première étape concrète vers l’Objectif de Produit. Chaque Increment s’ajoute à tous les Increments précédents et fait l’objet d’une vérification approfondie, ce qui garantit que tous les Increments fonctionnent ensemble. Afin de fournir une valeur, l’Increment doit être utilisable.
[…]
Toute la Scrum Team est responsable de la création d’un Increment qui ait de la valeur et qui soit utile, à chaque Sprint
Scrum Guide 2020
Un bon incrément produit nécessairement de la valeur, ou au moins, permet à l’équipe d’apprendre quelque chose (ce qui a aussi de la valeur).
Un bon incrément doit fonctionner. Ça peut sembler évidement, mais il me semble important de le rappeler. Surtout, cet incrément doit fonctionner une fois assemblé au reste du produit déjà existant (les incréments précédents).
En quoi l’incrément est-il lié à la Definition of Done ?
L’engagement que la Scrum Team prend sur l’Incrément est la Definition of Done (DoD). La DoD permet de construire l’incrément de la bonne façon. L’équipe s’engage sur sa DoD, pas sur l’Incrément lui-même.
Un incrément n’a pas forcément vocation à aller en Production. Tout dépend de la DoD de l’équipe. Dans certains cas, la Production est inaccessible à l’équipe, cela deviendrait alors contre productif d’inclure ce critère dans la DoD.
Comment mesurer l’efficacité de l’équipe dans la création de ses incréments ?
L’équipe a besoin d’éléments tangibles lui permettant de comprendre et mesurer son efficacité sprint après sprint. Plutôt que de se baser (à tort) sur la vélocité, je privilégie la mesure du temps de cycle.
Le temps de cycle, c’est le temps entre le moment où l’élément de travail (la story par exemple) est commencé et le moment où il est terminé (Done). On souhaite connaître le temps de cycle des éléments qui mènent à la création de l’incrément, puisque c’est l’incrément qui apporte la valeur. D’accord, mais pour quoi faire ?
Avoir un temps de cycle plus court permet de livrer plus rapidement. En livrant plus rapidement, on récupère plus tôt du feedback sur le produit. En tenant compte de ce feedback, on améliorera plus vite notre produit pour le faire correspondre davantage aux besoins réels. Apprendre plus vite permettra au PO de valider plus vite ses hypothèses et de faire avancer plus rapidement le produit dans le bon sens.
Réussir à mesurer le temps de cycle actuel sera un bon point de départ pour l’améliorer par la suite. Un graphique représentant l’évolution de ce temps (en jours ouvrés) sprint après sprint sera un bon sujet de discussion en rétrospective.
Comment optimiser son temps de cycle ?
Étudier le focus de l’équipe est une bonne piste pour réduire le temps de cycles des éléments du Sprint Backlog. Plus l’équipe est dispersée sur des tâches différentes, plus le temps de cycle risque d’être long. Le pair programming devrait aider l’équipe à avancer plus efficacement sur ses tâches, les unes après les autres. Deux développeurs travaillant ensemble vont terminer plus de tâches qu’en travaillant chacune de leur côté (voir Extreme Programming).
Limiter le nombre de développements en cours par personne permettra de réduire l’effet « tout est commencé, mais rien n’est terminé ».
Pour éviter un allongement du temps de cycle, l’équipe devrait être aussi capable de valider elle-même ses stories. Si les critères d’acceptation sont bien définis en amont, rien n’empêche l’équipe de passer la story à Done, même si une validation du PO est souvent la bienvenue.
Et pour aller plus loin ?
Questions à poser à l’équipe :
- Sommes nos capables de livrer 1 incrément par jour ?
- Si ce n’est pas le cas, qu’est-ce qui nous en empêche ?
Réfléchir à ces deux questions pourra certainement aider l’équipe à identifier des blocages et idéalement… à les résoudre !