Le secret du point d'effort utilisé pour les estimations des équipes agiles.
L’estimation en points est un concept qui peut paraître obscur pour une équipe qui démarre cette pratique. Je vous propose dans cet article une explication de ma vision du story point et mon conseil pour vous lancer.
Qu'est-ce que le point d'effort ?
Si vous vous plongez dans la théorie du point, vous retrouvez plusieurs types de points :
-Le point de complexité va permettre de définir le niveau de difficulté d’une User Story.
-Le point d’effort va de son côté plutôt permettre d‘estimer une durée de temps nécessaire pour réaliser l’User Story. Cela va inclure différentes notions à prendre en compte par l’équipe : la complexité, le niveau de maîtrise de l’équipe, la quantité de travail, les risques et inconnues, etc.
-On parle aussi de point métier ! Même si ce n’est pas le sujet de l’article, c’est l’occasion d’en parler. Le point métier va permettre de définir le niveau de plus-value de l’User Story une fois en production.
Personnellement, dans mes équipes, je préfère utiliser la notion de point d’effort. Je n’ai, personnellement, pas trouvé d’intérêt au point de complexité dans mes différentes équipes. Par exemple, une tâche simple peut être très coûteuse en temps. Je trouve important d’avoir un indicateur qui prend en compte le temps nécessaire à la réalisation et donc la complexité de la tâche. Mais alors, pourquoi s’embêter à parler en point et non pas en jours/hommes si on veut un ordre d’idée du temps nécessaire pour réaliser une User Story ?!
Pour deux raisons très simples :
-On parle d’estimation, pas d'une science exacte ! Le fait d’estimer en point d'effort me paraît moins angoissant pour les équipiers qu’une estimation en jour/homme que je vais pouvoir vérifier.
-Mais c’est combien un jour/homme ? Par exemple, si je réalise une tâche que je maîtrise en un jour/homme, je vais pouvoir produire une bonne partie du travail. Mais si c’est une tâche que je ne maîtrise pas, peut-on considérer que je produis la même valeur sur mon jour/homme ? Et puis, pour être transparente, je suis plus efficace le lundi que le vendredi, est ce que mon jour/homme a la même valeur le lundi que le vendredi ? Et si dans mon équipe j’ai un équipier junior et un équipier expérimenté, leur jour/homme est-il le même ? C’est bon, vous êtes en train de vous tirer les cheveux ?
Pour répondre à cette problématique, introduire une nouvelle notion (un point, une taille de t-shirt, une pinte de bière — oui j’ai déjà fait chiffrer en pintes de bière...) pour estimer nos tâches est la solution qui me paraît la plus simple. Peu importe l’unité choisie, elle sera propre à l’équipe et représentera la moyenne du travail fourni par l’équipe par jour. Cela signifie que c’est à l’équipe de déterminer la valeur de son point (ou toute autre unité) !
Lancer une équipe sur l’estimation en point
Déjà, on explique à toute l’équipe cette notion de point d'effort (ou on leur fait lire la première partie de cet article).
J’utilise des User Stories (US) étalons pour accompagner l’équipe dans cette nouvelle direction. C’est à dire que je prends deux User stories réalisées par l’équipe qui représentent le type de tâches qu’on retrouve souvent dans notre backlog : une User Story qui n’a pas pris beaucoup de temps et une user story un peu plus conséquente. Je vérifie que tout le monde a bien en tête le travail réalisé sur ces User Stories !
Arbitrairement, j’attribue deux points à la “petite” US et 8 points à la “grande”. Pour les prochaines estimations, je demande à l’équipe de réfléchir à la taille du travail à estimer en fonction de nos User Stories étalons. Classiquement, on utilise la suite de Fibonacci pour notre échelle d’estimation.
Quand un nouvel équipier arrive, on prend le temps de lui présenter nos US étalons. Cela lui permet de comprendre facilement la valeur de nos points.
Avant de pouvoir vraiment connaître notre coefficient de focalisation (le nombre de points produits par jour), je prends la moyenne des trois derniers sprints. Le nombre de points produits d’un sprint à l’autre n’est bien sûr pas égal ! Déjà puisqu’il dépend du nombre de jours où les équipiers sont présents dans l’itération et parce que nos équipes sont avant tout des humains ! Le coefficient de focalisation me permet de donner une indication aux équipiers sur leur capacité d’engagement du prochain sprint mais c’est leur ressenti qui validera l’engagement du sprint (Sont-ils à l’aise en terme charge avec le sprint backlog qu’on est en train de construire ?)
Mon point d'effort est-il fiable ?
A la fin de chaque itération, je calcule la prédictibilité, c’est-à-dire le nombre de points engagés versus le nombre de points réalisés. Le prédictibilité doit se situer entre 95% et 105%. Si je ne suis pas dans cette enveloppe et que je ne suis pas capable d’expliquer pourquoi nous n’avons pas tenu notre engagement, que cela se reproduit sur plusieurs sprints, c’est qu’il est peut-être temps de revoir la valeur de mon point d'effort.
La première étape, dans ces cas là, est de proposer aux équipiers de chiffrer à nouveau les User Stories du dernier sprint, avec la vision qu’ils en ont aujourd’hui puis de chercher à comprendre ce qui nous a échappé. Cela peut vous permettre de mettre en place une checklist des choses à ne pas oublier lors de l’estimation.
La deuxième étape est de réactualiser vos User Stories étalons en prenant deux nouvelles US , une petite et une grande, qui sont peut-être plus en lien avec votre actualité.
Le point et le management
Malheureusement, en tant que Scrum Master, il faudra souvent protéger votre point de certains managers toxiques.
“L’équipe A produit plus de points que l’équipe B” : Etant donné que le point d'effort est une valeur qui est propre à chaque équipe, cette affirmation ne signifie rien. Peut-être que l’équipe A a une valeur du point plus importante que l’équipe B ! Ne serait-il pas plus intéressant de suivre la valeur métier livrée en production ? Ou juste de se poser la question du gain apporté par la comparaison de deux équipes différentes ?
“On va objectiver l’équipe pour qu’elle produise plus de points” : Comme le développeur est un être malin, il va juste augmenter la valeur de ses estimations ! Encore une fois, ne serait-il pas plus intéressant de regarder la valeur métier livrée en production ?
“Quoi 5 points? Oh ! C’est une petite tâche de 3 points là” : On connaît le côté un peu négociateur de notre ami le Product Owner. Si l’équipe pense que le travail vaut une certaine valeur, elle a sûrement raison. On peut à nouveau échanger sur le contenu de l’User Story pour valider qu’on est alignés mais n’oublions pas que les personnes qui vont réaliser sont les meilleures pour estimer.
En conclusion, le point d’effort est un outil qui permet à une équipe de définir une moyenne du travail réalisable. C’est une notion qui est propre à l’équipe et qui ne peut servir qu’à celle-ci pour l’aider à estimer la quantité de travail qu’elle peut embarquer. Pour se lancer, l’équipe peut arbitrairement attribuer un poids à des User Stories déjà réalisées et comparer les futures tâches avec ces User Stories de référence.
Charline, Scrum Master chez Valeuriad, assistée par la tribu Agile interne pour la relecture.
Un grand merci à Manon, ma nouvelle collègue pleine de talents, pour ses illustrations
