Story Points : 5 minutes pour comprendre

Qu’est ce qu’un story point?

Un story point sert à estimer l’effort nécessaire à une équipe pour implémenter une fonctionnalité (story pour les intimes).

Cette estimation prend en compte :

• l’effort pour le développement
• la complexité du développement
• Le risque / l’inconnu

Par abus de langage, on dit que le story point sert à estimer la “taille” d’une fonctionnalité.

Pourquoi estimer ?

Il n’existe pas d’unité de mesure de la “taille” d’une fonctionnalité (en tout cas pas à ce jour) donc déterminer le coût d’une fonctionnalité nécessite forcément des estimations.

Comment estimer ?

Une estimation est souvent le résultat direct ou dérivé d’un calcul. Par exemple pour estimer le coût nécessaire pour peindre une pièce, il faut :

• chercher une grandeur de mesure (la surface d’une pièce dans notre exemple)
• estimer le coût en fonction de la surface et du coût par mètre carré

En l’absence d’une grandeur de mesure (comme pour les fonctionnalités), l’estimation peut se faire comme suit:

• chercher une unité de comparaison (une autre pièce de référence dans notre exemple)
• estimer le coût en fonction du coût de la pièce de référence multiplié par le rapport d’une pièce sur l’autre

L’estimation est donc relative ce qui la rend simple à faire: en effet, quand il s’agit d’estimer, il est plus facile de raisonner en relatif. Prenons une situation où il s’agit de déterminer le poids d’une boîte A. Pour garder l’analogie avec les tailles des fonctionnalités, disons que nous ne savons pas peser la boîte A. Dans ce cas là, c’est plus facile pour une personne de dire que la boite A pèse deux fois le poids de la boite B que de dire la boite A pèse 2,37 Kg.

Pourquoi ne pas estimer directement le temps nécessaire pour développer une fonctionnalité?

Pourquoi estimer la “taille” d’une fonctionnalité? Pourquoi ne pas prendre le temps comme unité de comparaison et faire des estimations relatives? Ce temps varie en fonction de la taille ou de l’expérience de l’équipe. Ne pas faire abstraction de l’expérience des membres de l’équipe rend les estimations divergentes et plus difficiles : en effet, avec une estimation en jours ou en heures, un développeur Junior peut estimer une tâche à 3 jours alors qu’un développeur avec plus d’expérience estimera la même tâche à une journée de travail.

Disposer d’une grandeur d’estimation qui soit propre à la story est donc nécessaire.

Ce raisonnement peut être retrouvé dans l’exemple suivant:

Combien de temps pour aller d’un point A à un point B ?: la réponse dépend forcément du moyen de transport et de sa vitesse (à pieds, à vélo, en trottinette, en fusée …). Pour avoir une réponse, il faut donc une estimation de la distance (en analogie avec la taille de la fonctionnalité). Ensuite, il suffit de calculer le temps nécessaire en fonction de la vitesse du moyen de transport.

La notion de “taille” d’une story est la grandeur propre à la fonctionnalité. Comme pour chaque grandeur, il y a besoin d’une unité de mesure et dans notre cas c’est le story point.

Comment estimer en story points?

Pour pouvoir estimer en relatif, l’équipe commence par choisir une ou plusieurs stories de référence en leur attribuant arbitrairement et d’un commun accord une “taille” chacune.

Ensuite, lors de la réunion de Planning Poker (aussi appelée réunion de chiffrage, d’estimation ou encore de cotation):

• La nouvelle fonctionnalité est présentée.
• Les membres de l’équipe posent des questions pour avoir plus de précisions.
• Chaque membre de l’équipe estime la “taille” de la fonctionnalité relativement aux tailles des stories de référence.
• Les membres de l’équipe dévoilent en même temps leurs estimations pour ne pas influencer les votes.
• Si les estimations ne convergent pas, les membres de l’équipe expliquent les raisons de leurs choix
• Le processus d’estimation est répété jusqu’à ce que tous les membres de l’équipe se mettent d’accord sur une estimation.

Se mettre d’accord sur une estimation ne veut pas forcément dire que tous les membres votent pour la même “taille”. Il se peut qu’un des membres de l’équipe donne une estimation supérieure à celles des autres. Dans ce cas, après discussion avec l’équipe et avec l’accord de tous les membres, l’estimation la plus haute est retenue.

Quelle échelle d’estimation?

Plusieurs séquences existent pour estimer la “taille” d’une fonctionnalité. Les plus utilisées sont :

• séquence avec une taille numérique (varie de 1 à 10)
• séquence avec la taille des vêtements (XS, S, M, L, XL, XXL) (souvent utilisé en Kanban)
• séquence de Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100) : séquence où chaque numéro est égal à la somme des deux numéros précédents.
• séquence (1, 2, 4, 8): séquence où chaque numéro est égal au double du numéro précédent.

Notons bien, que la séquence de Fibonnaci est un peu modifiée puisqu’à partir d’une certaine valeur la précision n’a pas beaucoup d’importance. Se baser sur des séquences non linéaires (comme les deux dernières) rejoint cette idée aussi et permet d’éviter de longues discussions autour de la “vraie valeur” de la taille d’une story. N’oublions pas qu’il s’agit toujours d’estimations.

Peu importe la séquence choisie, il faut que l’équipe se sente à l’aise avec celle-ci et qu’elle la retienne pour tous les chiffrages.

Comment déterminer les coûts de développement ?

Comment les estimations en story points peuvent nous aider à déterminer les coûts de développement des fonctionnalités? Pour le comprendre, il faut introduire la notion de vélocité.

La vélocité est une mesure de la capacité d’une équipe à réaliser des fonctionnalités sur une période donnée. Elle est calculée en sommant les story points des fonctionnalités terminées. Par exemple, une équipe qui termine le développement de deux stories estimées à 5 points et une story estimée à 3 points aura une vélocité de 13 points.

Ayant la vélocité de l’équipe, il est facile de déduire une estimation du temps nécessaire à partir de l’estimation des tailles des stories.

Conclusion

Ce billet de blog se concentre sur la technique d’estimation avec les story points. Cette technique n’est pas la seule, on peut citer l’estimation en jour idéal. En pratique, l’exercice d’estimation laisse place à différentes questions comme: que faire des stories non terminées à la fin des développements? quand réestimer les stories? comment estimer les stories quand on connaît pas la technologie ?