Les Story Points sont largement utilisés dans les approches agiles pour estimer l’effort à fournir pour développer et livrer ses User Stories. Ils permettent d’éviter les estimations en Jours-Homme et sont souvent préférés à une approche #noestimates .

Mais ils peuvent parfois paraître difficiles à mettre en œuvre pour les non-initiés. Cet article tente de guider un peu leur mise en place au démarrage d’un projet.

Pourquoi utiliser des Story Points pour les estimations

Le détail de ce que sont les Story Points et pourquoi les préférer à des jours hommes est très bien décrit dans un précédent article Estimation et Story Points.

Pour résumer, les Story Points permettent de mesurer une tâche en terme d’effort d’une équipe concrète, au lieu de simplement faire des estimations en jour-hommes, qui fluctuent selon les personnes.

Cette approche permet de :

• Réduire et contrôler les risques
• Réduire la part d’incertitude inhérente à tout projet
• Servir de support à la prise de décision et à la priorisation
• Établir la confiance
• Aligner l’équipe et partager l’information

Pour plus de détails, lire l’article mentionné ci-avant.

Comment démarrer l’estimation en Story Points

On utilise souvent, et on utilisera ici, la suite de Fibonnacci (1, 2, 3, 5, 8, 13, 21, …) pour décliner la quantité d’effort à fournir.

La suite de Fibonnacci apporte plusieurs avantages :

• l’avantage de forcer les choix sur une série de chiffres, ce qui permet de trancher plus facilement (comme dit l’adage : « il vaut mieux être approximativement juste que précisément faux »)
• l’avantage d’avoir un espace entre les chiffres successifs qui ne font pas passer du simple au double, mais suffisamment éloignés au fur et à mesure qu’il augmentent pour rendre la saut significatif, sans être hors de proportion.

Dans cet article, nous nous arrêterons à 21 comme nombre de points au delà duquel nous considérerons qu’une US est trop grosse et qu’elle doit être découpée. Pourquoi 21 ? Certains prennent 21 pour avoir plus de paliers de taille. D’autres préfèrent s’arrêter à 8 pour amener l’équipe à des US plus petites, ce qui est toujours une bonne chose. Cela dépendra de la maturité des équipes de développement et des Product Owners et de leur capacité à produire de telles US. La maturité est parfois un luxe dans certains contextes… Aussi, nous utiliserons ici 21.

Suite de Fibonacci (dont on utilisera un sous-ensemble)

Déterminer quelques User Stories de référence de taille moyenne

La mesure en Story Points est une mesure relative. C’est-à-dire qu’on estime l’effort nécessaire à faire une User Story relativement aux autres.

Pour cela, il faut d’abord créer un premier point de repère. Ce point de repère est déterminé en prenant un nombre suffisant de User Stories qui sont considérées par l’équipe comme étant de taille moyenne au regard de toutes les User Stories estimables.

Combien de User Stories prendre pour notre point de repère ? Entre 1 et 3. Cela dépend du contexte, de la variété des types d’US. Pour nos illustrations, nous en prendrons 3, bien que dans des projets moins complexes, on s’arrêterait à 1 ou 2 max.

Aussi, nous suivrons les étapes ci-après :

1. Le Product Owner rassemble toutes les User Stories qui sont suffisamment détaillées pour en estimer la taille et les présente à l’équipe. La bonne pratique veut que quelques membres de l’équipe aient participé à la clarification de ces User Stories en amont.
2. L’équipe choisit 1, 2 ou 3 User Stories qu’elle considère comme étant de taille moyenne par rapport à l’ensemble des User Stories. Ces User Stories seront le point de référence par rapport auquel on évaluera la taille de toutes les autres User Stories. On décrète qu’elles nécessitent un effort de 2, 3 ou 5 points. Nous utiliserons ici 5 points pour laisser 3 paliers de part et d’autre ([1,2,3] et [8, 13, 21]). D’autres préférerons 3 pour ne laisser que 2 paliers.
   

Déterminer la taille du reste des User Stories relativement aux User Stories de référence

1. L’équipe discute des User Stories restantes et leur attribue des Story Points en fonction de la suite de Fibonnacci. L’équipe peut utiliser pour cela des approches comme le planning poker (Xebia a créé une belle app mobile de planning poker), ou encore le velocity game, le pari de vélocité à vote secret, etc. Au choix des préférences.
   Une note : cet article sur les planning poker donne tous les bénéfices à utiliser ce genre de jeu, bénéfices qui vont bien au-delà d’une simple obtention de nombre de points.
   

À présent, les User Stories qui étaient suffisament détaillées sont estimées. Vous pouvez commencer à les utiliser dans vos sprints.

À noter que, dans le cas présent, une des User Stories a été considérée comme trop grosse (21 points dans notre exemple) et devra donc être redécoupée.

Comment déterminer la vélocité de départ d’une équipe

Au début des développements, l’équipe n’a pas encore utilisé les Story Points qu’elle vient de définir. Elle n’a même peut-être jamais travaillé ensemble. Ou encore, elle n’a pas travaillé dans le contexte spécifique de l’entreprise ou du projet. Pour toutes ces raisons, elle ne peut pas connaitre d’emblée sa vélocité, c’est-à-dire le nombre de Story Points qu’elle peut livrer en un sprint.

Aussi doit-elle déterminer une première vélocité sans historique préalable. Pour cela, elle va étudier par ordre de priorité les User Stories, et s’accorder sur jusqu’où elle pense pouvoir aller dans son 1^er sprint.

Pour ce faire :

1. Les membres de l’équipe prennent les User Stories par ordre de priorité et décident ensemble, par consensus, jusqu’à quelle User Story ils pensent que l’équipe est capable d’aller.
2. Les Story Points des User Stories choisies sont additionnés : c’est la première estimation de vélocité d’équipe, qui est estimée mais pas encore mesurée.

Premières mesures de vélocité et vélocité stabilisée

Quelques points à savoir sur la stabilisation de la vélocité

En général, au démarrage de la vie d’une équipe, beaucoup de choses se mettent en place. Ceci va avoir un impact sur la capacité de l’équipe à livrer.

Par exemple :

• Les outils de développements ont été fraichement mis en place
• Les serveurs d’intégration continue sont tout juste opérationnels
• L’équipe n’a pas encore travaillé ensemble
• L’équipe découvre le produit
• …

Pour toutes ces raisons, en règle générale, on dit qu’il faut attendre a minima le 3^e sprint avant de considérer que la vélocité de l’équipe est stable, c’est-à-dire que celle-ci a atteint une vitesse de croisière. Ceci, bien sûr, à condition que l’environnement et le contexte de l’équipe soient également stables. Nous disons bien : le 3e sprint a minima. Les démarrages peuvent s’avérer plus compliqués, et repousser d’encore quelques sprints l’arrivée de conditions stables pour considérer la vélocité comme stabilisée.

A noter que si l’équipe ou l’environnement de l’équipe (technique, opérationnel, …) ne sont pas stables, alors on ne peut pas avoir d’estimation correcte, que ce soit en agilité ou dans n’importe quelle autre approche. Il faudra donc adresser les problèmes qui perturbent cette stabilité.

Premières mesures et ajustement de vélocité

Reprenons là où nous nous étions arrêtés au début du sprint 1. La vélocité de départ a été déterminée. Le sprint 1 a été lancé.

Par la suite :

1. Une fois le sprint 1 terminé, on additionne les points des US effectivement Done par l’équipe. C’est la première vélocité effectivement observée.
2. Si le sprint s’est passé sans perturbation particulière, on prend cette première vélocité pour déterminer les US sur lesquelles l’équipe peut s’engager pour le sprint suivant. Attention, on peut revoir la vélocité attendue au sprint 2 si des événements particuliers ont perturbé l’équipe durant le sprint 1, ou qu’on sait par avance qu’il y aura des événements particuliers qui vont affecter le sprint 2 (congés de la moitié de l’équipe, par exemple).
3. On fait de même à la fin du sprint, et au début du sprint suivant

Au bout de 3 sprints a minima, ou plus comme indiqué plus haut, sauf si des événements ont continuellement perturbé les sprints, on considère que la vélocité est stabilisée et qu’on peut l’utiliser pour des projections. Les projections sont un autre sujet qui sera abordé dans un article ultérieur.

Voilà. Vous avez maintenant une vélocité d’équipe qui a tenu les tests du temps.