Dans les méthodes agiles, on n’estime pas le travail à réaliser comme dans les méthodes prédictives. Si vous avez l’habitude de réaliser des estimations en jour/homme, il va falloir revoir votre manière de faire, et dire bonjour aux story points.
Dans cet article, je vous explique ce qu’est un story point, pourquoi est-ce qu’on les utilise plutôt que les jours hommes, et je vous livre également des conseils pour bien estimer vos story points tout en évitant les pièges classiques.
Qu’est-ce qu’un story point ?
Définition d’un story point
Un story point, ou point d’effort, est une unité de mesure utilisée dans les projets agiles, qui permet d’estimer l’effort nécessaire pour accomplir intégralement une tâche du backlog produit. Les story points sont assignés en fonction de la capacité de l’équipe, la complexité du travail à réaliser, le risque associé et l’incertitude.
Ces points d’efforts servent à estimer la charge de travail globale de l’équipe agile, afin de planifier au mieux chaque sprint ou chaque itération du projet. Si la capacité de l’équipe pour le prochain sprint est de 50, l’équipe agile va donc planifier le développement de X fonctionnalités pour un total de 50 points.
Les story points des différentes fonctionnalités à développer sont estimés collectivement lors du planning poker, en utilisant une fonctionnalité de référence.
A noter que la mesure en points d’effort est une estimation relative. Cela veut dire qu’on estime l’effort nécessaire pour réaliser une tâche ou fonctionnalité (une user story) relativement aux autres, plutôt que de prendre chaque tâche de manière indépendante.
Pourquoi utiliser les story points plutôt que les estimations jour/homme ?
Les estimations en jour/homme varient selon de nombreux facteurs, tels que l’expérience de la personne en charge de l’estimation ou sa rapidité d’exécution.
Deux personnes ayant le même niveau de compétences et d’expérience peuvent très bien donner des estimations différentes, parfois avec un écart x2 ou supérieur.
Certains parlent même de « prédiction au doigt mouillé » concernant les estimations jour/homme. Dans les méthodes agiles, on veut justement éviter ce phénomène d’effet tunnel, où l’on estime 30 jours de réalisation pour au final se retrouver avec plus de 65 jours au compteur.
Voici une analogie pour bien vous expliquer la différence entre un point d’effort et une estimation jour/homme.
On ne court pas tous à la même vitesse, et certains vous annonceront 20 minutes pour faire une course de 5km quand il en faudra 60 minutes pour d’autres.
Vous pourriez très bien faire une moyenne des différentes réponses obtenues, mais cela ne vous dirait pas collectivement combien de temps l’équipe mettrait. Sauf que vous ne savez pas à l’avance qui va courir, vous ne savez pas à l’avance s’il y a des obstacles sur le chemin ou pas.
Vous pourriez très bien vous lancer dans des calculs complexes, mais au final le résultat obtenu serait toujours faux, et vous auriez bien du mal à mettre tout le monde d’accord.
Par contre, tout le monde s’accorde à dire que la course fait bien 5km. Tout le monde sera d’accord également pour dire qu’une course de 10km représente deux fois plus d’efforts que celle de 5km.
Différentes estimations en jour/homme © Publicis Sapient
Les story points mettent tout le monde d’accord © Publicis Sapient
Avantages des story points
Pourquoi perdre notre temps et notre énergie à essayer d’estimer de manière ultra précise le temps que prendra chaque tâche sur un projet si le résultat sera de toute façon faux ?
C’est en partant de cette question que les agilistes ont choisi l’estimation relative (les story points) plutôt que l’estimation absolue (les jour/homme). C’est certes moins précis et plus grossier, mais ça fait largement le job.
Voici les principaux avantages reconnus lorsqu’on utilise une méthode d’estimation relative telles que les points d’effort :
- Réduire les risques de mauvaises estimations.
Une estimation est par nature imprécise. Et plus le travail à estimer est grand et complexe, plus la marge d’erreur est importante. C’est ce qui explique pourquoi autant de projets classiques prennent du retard sur la date de fin initialement annoncée. - Accélérer la planification.
Le travail d’estimation de la durée de chaque tâche est long, fastidieux et énergivore, pour un résultat plus qu’incertain. Les story points quant à eux peuvent être attribués bien plus rapidement et facilement,c e qui permet d’accélérer la phase de planification du projet. - Tenir compte des risques et de l’incertitude.
Il peut survenir mille et une choses imprévues en cours de route qui peuvent augmenter la durée nécessaire pour finaliser une tâche. La valeur des points d’effort tient compte du risque de la tâche à réaliser, des difficultés potentielles, et de l’incertitude liée à cette tâche. On a donc beaucoup moins d’écarts possibles avec les story points qu’avec les estimations en jour/homme. - Gagner en flexibilité.
Si le client change des priorités en cours de route, l’équipe agile peut décider de sortir du prochain sprint une fonctionnalité représentant 5 points d’efforts pour en mettre d’autres à la place pour un total de 5 points d’efforts également. Le client et l’équipe gagnent ainsi tous deux en flexibilité. - Estimations plus justes réalisées à plusieurs.
L’estimation de la valeur des points d’efforts est réalisée de manière collective, ce qui permet de s’assurer qu’une seule personne n’est pas passé à côté de quelque chose. Les notes extrêmes sont justifiées et débattues jusqu’à ce que l’équipe trouve un consensus. - Estimations relatives qui s’améliorent au fil du temps.
Au fur et à mesure du projet, l’équipe apprend à travailler plus efficacement. Et ce qui prenait 13 story points il y a quelques semaines n’en prend peut-être plus que 5 aujourd’hui. Estimer les points d’effort de manière relative permet d’avoir des estimations plus justes par rapport à la capacité actuelle de l’équipe.
Quand peut-on attribuer les story points ?
Les story points sont attribués collectivement par l’équipe projet à chaque user story lors du planning poker, qui peut se dérouler soit pendant le backog refinement soit pendant le sprint planning.
Le product owner priorise en amont de ces réunions les user stories, et met en avant celles à travailler. L’équipe projet « joue » alors au planning poker afin d’obtenir un consensus sur les points d’effort à attribuer à chacune de ces user stories.
Enfin, l’équipe tient compte de ces points d’efforts pour planifier le prochain sprint, en choisissant d’y ajouter toutes les fonctionnalités qu’elles pensent pouvoir réaliser durant cette itération.
Quelle est l’unité recommandée pour les story points ?
On utilise le plus souvent la suite de Fibonacci afin d’estimer les points d’effort en agilité, qui apporte un avantage non négligeable : plus on grimpe dans les chiffres, plus l’écart entre deux chiffres est important, ce qui permet de rendre le saut vraiment significatif.
Passer du 8 au 13 se réfléchit, alors que passer du 8 au 9 pourrait faire longuement débat.
Bien qu’il existe plusieurs utilisations de la suite de Fibonacci, la plus courante est celle représentée en rouge sur l’image ci-dessous. Il s’agit d’un sous-ensemble de la suite, qui part de 1 et s’arrête à 21. Les valeurs possibles pour les story points sont donc :
1 – 2 – 3 – 5 – 8 – 13 – 21.
Et voici la représentation de la suite de Fibonacci
Il existe un dérivé qui a ma préférence, et qui fait sauter le 2 des valeurs possibles. Pourquoi ? Car attribuer un point d’effort entre 1, 2 et 3 peut amener beaucoup de débat au sein de l’équipe, et pas forcément constructifs.
Dans cette variante, on retient donc les chiffres suivants : 1 – 3 – 5 – 8 – 13 – 21.
De manière générale, tout ce qui serait au-dessus de 21 devrait-être redécoupé en unité plus petite, afin de faciliter l’estimation des points d’effort.
Pour aller + loin : Découvrez dans cet article les différentes manières d’estimer les user stories et d’attribuer les story points, de la suite de Fibonacci aux tailles de tshirt.
Comment estimer les story points ?
- Déterminer l’unité de mesure.
Commencez par déterminer quelle unité de mesure vous allez utiliser pour vos points d’effort. Je vous recommande d’utiliser les tailles de tshirt ou le sous-ensemble de la suite de Fibonacci 1 – 3 – 5 – 8 – 13 – 21. - Déterminer l’étalon de référence.
Prenez une user story qui représente 3 points d’effort selon l’équipe. Cette user story servira de point de référence pour le reste des fonctionnalités à estimer. Cela vous permettra de bénéficier de tous les avantages d’une mesure relative. - Analyser les user stories.
Faites un tour de l’ensemble des user stories que l’équipe doit estimer. Profitez-en pour laisser l’équipe poser toutes les questions nécessaires afin de mieux comprendre quel est le travail à réaliser. - Tenir compte de tous les éléments pour estimer vos points d’effort.
Pour que vos estimations soient les plus précises possibles, il convient de tenir compte des facteurs suivants :- Complexité de la tâche.
- Volume du travail à réaliser. On le nomme également le « travail pour faire ».
- Risques éventuels et incertitude dans la réalisation de ce travail.
- Définir la valeur des points d’effort de chaque user story.
Enfin, faites un tour de planning poker. Si l’équipe obtient un consensus, vous pouvez passer à la user story suivante.Autrement, demandez aux notes extrêmes d’expliquer pourquoi ces notes-là, puis relancez un tour d’estimation en tenant compte des informations apportées.L’équipe doit obtenir un consensus sur les points d’effort.
Les pièges à éviter avec les story points
Voici les 7 pièges les plus courants que l’on fait avec les story points :
- Convertir les points d’effort en jour/homme.
1 point = 1 heure est une très mauvaise idée, qui annule le principal avantage des story points : la mesure relative, qui permet d’avoir rapidement un consensus de groupe. - Ne pas avoir de cadre de référence.
Un point d’effort doit être estimé relativement par rapport à un autre travail donné. L’équipe choisit le plus souvent une fonctionnalité avec un story point de 3 comme cadre de référence, afin d’estimer les points d’effort des autres fonctionnalités. - Faire une moyenne des points obtenus au planning poker.
Tout l’intérêt de cette méthode d’estimation est d’obtenir un consensus dans l’équipe. Réaliser une moyenne est le meilleur moyen de ne mettre personne d’accord, tout en ayant une estimation faussée. Préférez demander des explications aux notes les plus basses et plus élevées, puis faites un nouveau tour de table. - Estimer les story points à la volée ou au doigt mouillé.
Non, vraiment, quel intérêt ? Je me le demande… Autant ne rien estimer du tout dans ce cas. - Ne prendre en compte que la complexité d’un travail.
Sans doute l’erreur la plus courante. L’équipe peut passer à côté d’une tâche relativement simple mais demandant beaucoup d’efforts sur les tests, la documentation, etc. Prendre en compte uniquement la complexité d’un travail revient à sous-évaluer les user stories, et à fausser la planification du prochain sprint. - Ressortir la même estimation que le travail similaire du sprint précédent.
C’est tentant, mais ce n’est pas parce qu’on a mis 8 d’effort il y a quelques sprints qu’il faudrait garder cette valeur au sprint suivant. L’équipe a pu évoluer : turnover, congés, apprentissage, nouvelles manières de travailler. Il convient de réaliser une nouvelle estimation en tenant compte du contexte de l’équipe. - Prendre un story point comme un engagement ferme et définitif.
Le nombre de points n’est surtout pas un engagement sur le temps maximal à passer dessus. Il s’agit d’une estimation, et comme toute estimation, il y a un certain degré d’imprécision qui va avec.
Comment piloter un projet avec des story points ?
Un projet agile ne se pilote pas de la même manière ni avec les mêmes indicateurs qu’un projet traditionnel. Exit les plannings détaillés et autres joyeusetés.
Il existe à mon sens 3 indicateurs qui permettent de mesurer l’état d’avancement d’un projet agile :
- La vélocité de l’équipe.
Elle se calcule directement à partir des points d’effort. Je vous en parle plus en détails dans le paragraphe suivant. - Le burn-up chart.
Le burn-up chart est un graphique qui permet d’analyser l’avancement du travail réalisé jusqu’à maintenant par rapport à la globalité du projet prévu. Il est mis à jour à chaque fin de sprint, et permet d’estimer le nombre de sprints restants à périmètre égal sur le projet. - Le burn-down chart.
Le burn-down chart est un graphique qui permet d’analyser la quantité de travail restante pour une période donnée. Il est donc souvent utilisé pour mesurer l’avancement du travail d’une équipe sur un sprint.
Qu’est-ce que la vélocité de l’équipe et comment la calculer ?
La vélocité est un indicateur de mesure qui permet de mesurer la capacité d’effort qu’a fourni l’équipe sur les précédents sprints, et donc qui permet d’estimer la capacité de travail que cette équipe pourrait réaliser sur de futurs sprints.
Cet indicateur se calcule à la fin de chaque sprint en prenant le total des points d’effort des fonctionnalités réalisées à 100% en cours de sprint.
L’équipe agile peut se servir de cet indicateur lors du sprint planning afin d’éviter de prendre trop de user stories d’un coup.
Pour aller + loin : Je vous invite à consulter ce guide complet pour tout savoir sur la vélocité de l’équipe.
