12 Points ! L’utilisation des Story Points en mode Agile

Alors on est parti vers l’agilité ? A un moment il faudra estimer les user-stories (vous les appelez macro-tâches ou autre, ce n’est pas important). Nous avons besoin de savoir ce que l’on peut faire dans une itération, pour avoir un minimum de planification.

En particulier dans Scrum on évite d’estimer en vrais jours, pour plusieurs raisons (j’en  présenterai certaines plus tard). Chaque équipe trouve une façon d’abstraire le problème à un niveau suffisamment simple, mais en même temps assez pratique pour s’organiser : certaines équipes utilisent les tailles de t-shirts (XS de XXXL), d’autres la suite de Fibonacci (1,2,3,5,8…). Parfois on commence avec les “jours idéaux” et petit à petit nous arrivons à les convertir en quelque chose de plus abstrait. Le but est de trouver une approximation satisfaisante du temps relatif à développer une fonctionnalité, à +/- 50% par user story. C’est exactement cette notion d’approximation qui permet aux équipes d’estimer rapidement les stories. L’acceptation de cette approximation fait qu’en Scrum on n’utilise pratiquement jamais des chiffres exacts en jours (au contraire d’autres méthodologies agiles).

Parmi les échelles à utiliser, la séquence Fibonacci est la plus répandue, parce qu’elle permet une estimation rapide ET qu’elle permet d’ajouter les estimations pour voir au total combien de stories nous pouvons faire par itération. C’est facile de dire “nous estimons que nous faisons 120 points par itération” et chercher une série des stories avec un coût total d’à peu près 120 – c’est plus difficile quand il faut ajouter 2 stories “Extra Small” à 3 autres “Large”.

La précision de la méthode

Je vous préviens : c’est le moment où vous aurez des frissons. Soit parce que vous vous y connaissez assez en statistique pour comprendre que la méthode est loin d’être exacte, soit parce que vous n’en connaissez pas assez et les paragraphes suivants vont vous fatiguer. Dans le second cas, vous pouvez passer directement aux conclusions.

Disons que nous commençons avec 10 estimations qui ont un marge d’erreur de +/-50% avec un niveau de certitude de 95% (ie la probabilité de tomber dans le [-50%, +50%] est au moins 95%). Imaginons que ces estimations “naturelles” seraient à peu près les suivantes :

1 3 7 7 12 15 17 21 25 28 = 134

Si nous les forçons à respecter l’échelle de Fibonacci, nous ajoutons une erreur de mesure :

1 3 8 8 13 13 21 21 21 34 = 141

Heureusement, cette erreur n’ajoute pas de “biais” systématique (il n’y a pas de raison de dire qu’à cause de l’échelle de Fibonacci nous sous-estimons ou surestimons systématiquement). Elle augmente par contre la marge d’erreur par estimation. Disons, pour être gentils, qu’elle l’augmente de 50% à 60%. Donc cette story à 34 points pourrait en réalité (avec un niveau de confiance de 95%) prendre de 15 à 53 points (je vous assure que ça arrive assez fréquemment).

Heureusement, comme nous le savons des probabilités ou de la statistique, il n’y a pas de fortes chances que TOUTES les estimations soient au-dessus de la cible (pour une équipe qui a déjà pratiqué la méthode et connaît ses compétences). Pour 10 estimations comme celles au-dessus, la variance absolue du total est à peu près (pour éviter de sortir les suites statistiques et les calculatrices) de l’ordre de +/- 35 points.

Une des suppositions pour ce calcul est que les erreurs sont décorrélées, c’est à dire que l’erreur de l’estimation d’une story n’affecte pas les autres. Nous savons bien que ce n’est pas le cas. Une story peut être le prérequis pour une autre, et si la 1ère est bloquée, la 2nde avancera très lentement aussi. De même, un évènement bloquant (un serveur d’intégration en panne, par exemple) bloquera tous les développements.

En plus, les estimations ne sont pas toutes faites au même instant dans le temps. La même tâche pourrait être estimée à  8 points à l’itération 1, et à 5 à l’itération 5, quand l’équipe est plus expérimentée avec les technologies choisies pour le projet. Si elle est au final implémentée à l’itération 6, on va la comptabiliser différemment en fonction de quand elle a été estimée. L’échelle n’est même pas constante entre les stories de la même itération.

Vous comprenez alors que le vrai coût de ces tâches peut varier dans notre cas (et un peu au feeling) entre 90 et 190 points.

Conclusions

Ce n’est pas une métrique de performance à court-terme

Dans Scrum, avec les itérations courtes et le focus sur des résultats immédiats, c’est facile d’oublier de penser à long terme. Les managers externes et les clients voient que l’équipe a fait cette semaine 30 points de moins que la semaine d’avant et tout de suite se demandent ce qu’il s’est passé.

J’ai vu des équipes dire « C’était une bonne itération. Nous avons fait les points » ou « Dans cette itération nous étions mauvais. Nous n’avons pas terminé 2 stories » C’est une illusion. Les équipes ont une progression en productivité tardive qui peut justifier une augmentation d’à peu près 5% par itération. Mais ça n’arrive pas souvent d’oublier comment faire les choses d’une itération à l’autre. La plus grande source de variabilité entre itérations est juste le fait que nous n’avons pas assez d’informations pour estimer correctement.

Bien sûr, il y a aussi des évènements qui impactent le sprint : une nouvelle personne qui n’est pas encore habituée aux méthodes de l’équipe. Un nouvel outil qui rend une tâche récurrente plus rapide. Ces éléments, il faut les discuter dans la rétrospective du sprint (ou n’importe quelle cérémonie de feedback adoptée par l’équipe). Mais la détection de ces éléments est basée sur des méthodes qualitatives, pas quantitatives. Nous ne pouvons pas le voir juste en regardant le nombre de  points implémentés.

C’est une métrique très approximative de productivité à long terme

Une pratique assez commune, souvent utilisée pour vendre au management l’idée de « progrès de productivité » est de faire une régression linéaire pour présenter l’évolution de nombre de points implémentés par sprint (et souvent par jour-homme). A première vue, elle parait raisonnable : même si l’erreur de chaque estimation est élevée, la tendance  vers une progression devrait être visible.

Mais nous avons vu que les estimations ne sont pas toutes effectuées au début du projet. Une partie de l’augmentation de productivité est cachée par le fait que nous allons estimer les tâches suivantes sur la même technologie comme plus faciles.

Et si maintenant la hiérarchie a la superbe idée d’établir des objectifs sur le nombre de points, les développeurs risquent de commencer à surestimer volontairement. Dans un projet, la semaine ou le directeur a annoncé un objectif de nombre de points, l’équipe de développement a commencé à affecter des story points aux bugs. Donc l’équipe avait intérêt à sortir une story avec des bugs, comptabiliser les points de la story et, dans les itérations suivantes, recomptabiliser cette story en réparant les bugs détectés :D.

Il ne faut pas oublier, alors, qu’un des buts des story points est d’avoir un outil INTERNE à l’équipe et une échelle qui n’est pas influencée par les jeux politiques ou l’évaluation par les managers.

C’est suffisant pour l’organisation de l’équipe

Vous allez me dire “quoi ?! C’est suffisant ? Une estimation à +/- 35% ?”. Oui, c’est suffisant. Nous savons que le logiciel est compliqué. Il y a trop d’inconnues.  Les projets qui dépassent leur coût ou temps estimé de 100% ne sont pas rares. Même si à long terme les erreurs d’estimations vont suivre une distribution normale et si nous arrivons à estimer correctement la charge, nous ne pouvons pas estimer le nombre de nouvelles requêtes client, les changements de spécifications etc… Il y a des gens qui acceptent ça et rejettent complètement la notion des deadlines.

Ce qui est important, c’ est que, grâce à cette procédure, une équipe de 5-6 personnes peut rapidement communiquer une vision approximative de sa vélocité et permettre au client ou au product owner de leur affecter du travail, tout en respectant les priorités du client.

Nous pouvons faire mieux

On peut toujours dépenser un peu plus de temps à l’estimation :

• Noter sur les stories les dépendances (si nous avons fait la X, la Y sera plus rapide à faire). Ceci permet de réduire la “corrélation des erreurs”.
• Passer un peu plus de temps pour estimer les sous-tâches d’une story. Si, après l’analyse (mais avant l’implémentation), elle est plus ou moins chère que prévu, on doit prévenir le product owner. Cette mesure permet aussi de réévaluer des stories estimées trop loin dans le passé, quand la productivité et l’incertitude étaient différentes.
• Abolir l’échelle Fibonacci, et permettre au consensus d’arriver aux chiffres autres que 1,2,3,5…

Je ne préconise pas d’avancer avec ces ajustements tout de suite – nous pouvons arriver à cette précision lorsque l’équipe a pris l’habitude de la méthode et apprend à estimer plus rapidement.

Avec les bons ajustements, pour le cas présenté dans cet article, on pourrait réduire la variance à +/-25 points. Chaque équipe effectue ses ajustements et avec le temps l’estimation par story points donne des bons résultats. Pourquoi ? Parce que c’est le bon niveau d’abstraction. Sans trop se perdre dans les détails et commencer à comptabiliser les heures en réunions, la productivité relative dans l’équipe etc, nous arrivons à mesurer la vélocité de façon efficace.

Au final, les story points sont un outil. L’important reste les principes de l’agilité (ou du Scrum. Pour un bon article sur la séparation entre principes et outils, je propose Scrum Breakfast). Les pratiques et les outils sont à adapter à chaque équipe et, surtout, à utiliser pour le but pour lequel ils ont été créés.