Estimation Agile : Les Story Points - Dos & Donts

Si vous faîtes du développement de produit avec l'Agile, vous utilisez le framework Scrum ou XP, vous êtes Product Owner, Scrum Master ou Développeurs; ou si vous planifiez vos Sprints avec le Poker Planning, vous avez surement dû entendre parler des points d'estimation, points de complexités, ou tout simplement Story Points.

Originaire du XP, son instigateur Ron Jeffries, dis, je cite : "I like to say that I may have invented story points, and if I did, I’m sorry now.". Ce qui montre ô combien sa mise en pratique dans la plupart des équipes agiles voire des organisations est impertinente et source de plusieurs dysfonctionnements. Nous allons tenter dans la suite de ce post d'en souligner quelques, et d'y apporter des précisions.

Mais avant tout, un Story Point, c'est quoi déjà?

I - Origines et raison d'être

Les Story Points tirent leur origine de XP (oui vous avez bien lu, pas de Scrum) qui est une méthode agile précurseur de plusieurs pratiques de développement logiciel.

Initialement, les tâches à faire dans un projet étaient estimées de manière absolue, en nombre d'heures ou jours. Par exemple la fonctionnalité de création d'un utilisateur pouvait être estimée par le développeur Samba NDIAYE à 8H de travail. Son chef de projet, Product Owner ou bien son manager pouvait considérer qu'après 8H de temps cette tâche doit être bouclée par Samba.

On peut noter qu'avec cette façon d'estimer, les 8H communiquées par Samba NDIAYE, qui à la base sont une ESTIMATION (noter l'écriture en capitale) du temps idéal qu'il faut à Samba pour réaliser cette fonctionnalité. Ce qui se différencie du temps réel que cela lui prendra pour le réaliser. La confusion commence déjà à s'installer.

Surprise! Le lendemain au daily stand-up, Samba n'a toujours pas terminé sa tâche. Le Product Owner, le Chef de projet ou autre acteur du projet s'étonne que cette tâche ne soit toujours pas clôturée. Bonjour les dégâts!

Ce phénomène est très fréquent dans les équipes de développement. Parce que le développement logiciel étant un domaine complexe. Développer une fonctionnalité s'apparente à gravir une colline : on arrive difficilement à savoir le temps que cela prendra réellement, tant qu'on a pas encore atteint le sommet de la colline.

Ce qui veut dire qu'un développeur a besoin de démarrer le codage, d'évaluer la complexité réelle du développement pour mieux se prononcer sur sa réalisation. De ce fait, vouloir faire une estimation "exacte" dans la phase de planification est difficile et s'avère peut fiable.

Pour pallier à ce problème de confusion, Ron et son équipe (version raccourcie de l'histoire) sont passés au story points, un moyen pragmatique et efficace d'avoir un sizing (estimation) nécessaire pour évaluer la capacité à faire, et enfin démarrer les travaux.

II - Leurs avantages

• Ils ont de ce fait commencé à utiliser un système à point (les story points), abstrait et sans unités, donc décorrélé du temps nécessaire à la réalisation de la tâche. Ainsi, l'objectif de vouloir sizer (estimer) les tâches et définir la capacité à faire est toujours réalisable, sans créer la confusion sur le temps de livraison nécessaire. Mieux, il englobe tout ce qui peut être considéré dans la "complexité" (expérience de l'équipe, connaissance du domaine, incertitudes, etc.).
  
  

• Les développeurs sont donc plus à l'aise à se prononcer sur la complexité des tâches, sans nul besoin de surestimer, de prendre des marges, au risque d'être pris pour coupable de pas avoir livré dans les délais.
  
  

• Ils favorisent également ainsi la communication entre les membres de l'équipe. Au lieu de focaliser les discussions sur la durée estimée, l'équipe essaie plutôt de discuter des sujets à traiter pour les comprendre au mieux, identifier éventuellement les risques, dépendances et complexités inhérentes, et faciliter donc sa mise en oeuvre.
  
  

• Un autre avantage induit : l'estimation relative. En effet, du fait de l'abstraction des points, estimer devient plus simple en se basant sur un élément de référence. Ce qui joue en faveur de l'humain, car on estime mieux et plus rapidement un backlog avec cette estimation relative, en faisant des comparaisons sur un élément de référence.
  
  J'ai l'habitude de donner l'analogie qui suit dans mes formations : <<< Choisissez 3 objets autour de vous : (par exemple un stylo, un téléphone, un carnet de post-it). Estimez le poids "exact" des 3 objets. Ils vont vous dire respectivement : 5 grammes, 200 et 100 grammes. Avec beaucoup de difficultés de s'accorder sur un chiffre avant de le communiquer.
  

  Ensuite je leur demande : Estimez relativement le poinds de chaque, en le comparant au poids du stylo qui est l'élément unitaire de référence. En quelques secondes, ils vous diront que les post-its valent 5 fois le stylo, et le téléphone 10 fois par exemple. Avec beaucoup plus d'aisance >>>
  
  

• Les story points sont facilement manipulables. Ils sont additifs et permettent de faire des projections (forecasts). Le calcul de la vélocité (la vitesse d'execution ou la capacité à faire de l'équipe) prend ainsi tout son sens. Elle se mesure en faisant la somme du nombre de points réalisés dans un sprint. Dans le cas d'une estimation absolue par heures, la vélocité (horaire) ne pourrait excéder le nombre d'heures de travail cumulées dans un sprint. Cette vélocité avec les points est donc évaluée de manière empirique et s'affine au fur et à mesure que l'équipe se stabilise, s'améliore, et gagne en expérience sur le produit et sur leurs estimations.
  
  

• Il est très connu d'utiliser la suite de Fibonacci (l'originale ou bien la version allégée) pour estimer avec des points. Cette suite présente l'avantage d'avoir une complexité croissante cumulative, chaque point prenant en compte la complexité du précédent, de sorte à garantir un certain écart entre deux complexités successives. Ce qui permet d'améliorer les estimations et projections.
  
  

III - Anti-patterns

Maintenant, discutons quelques anti-patterns qu'on observe dans plusieurs organisations :

1. Comparer deux équipes sur base de leurs vélocités

Certaines entreprises utilisent cette vélocité comme métrique de mesure de la performance d'une équipe. Par exemple, une équipe A qui livre 50 points par Sprint est plus performante qu'une autre équipe B qui elle, livre que 30 points ou moins. Ce qui n'a absolument pas lieux d'être. Parce que d'abord il n'y pas de corrélation entre la performance et le nombre de points qui se veut abstrait, comme évoqué plus haut. Ensuite le contexte change d'une équipe à l'autre. Les estimations de l'équipe A se basent sur la taille de l'équipe, leur connaissance du produit, leur expérience dans la collaboration, leurs expériences individuelles, leur niveau de séniorité, etc. Vouloir comparer ces deux équipes sur base d'un chiffre qui ne reflète aucun de ces aspects, est un énorme raccourci et du non-sens tout bonnement.

2. Objectif de 30 Story Points par équipe dans chaque Sprint

Un prolongement du point précédent. J'ai vu des organisations qui fixent ces "objectifs" aux équipes. Les conséquences de cela sont désastreuses :

• D'abord ce n'est pas un vrai objectif
• Les équipes se concentrent sur le nombre de points, donc gonflent les estimations, plutôt que de se focaliser sur ce qui produit de la valeur à la fin du sprint. Et comme le dit l'adage : "Montre moi comment tu me mesures, je te montrerai comment je me comporte."
  
  

Si vous voulez des story points élevés vous aurez des story points élevés. Si vous voulez 30 points par Sprint, vous aurez 30 points par Sprint. Eh oui! Normal.

3. Objectif : Augmenter de X% la vélocité de l'équipe

Un autre prolongement du premier anti-pattern. S'il n'y a pas de corrélation entre vélocité en points et performance de l'équipe, à quoi bon se fixer un objectif d'accroitre la vélocité de 30 points et aller à 40 points? quid de la qualité de la production? ou de la valeur à créer?

C'est encore plus ubuesque si le management d'une telle équipe leur met une pression pour relever ce chiffre, dans l'optique, selon eux, de livrer "plus" et donc gagner en performance.

Le meilleur moyen de délivrer de la valeur, ce n'est pas en faisant "plus". Mais plutôt d'avoir un flux optimisé, qui permet de livrer de petits bouts fréquemment et en continu.

Livrer fréquemment des bouts fonctionnels, en quelques semaines voire quelques mois, avec une préférence pour la courte durée. - Principe 3 du Manifeste Agile

4. Vélocité individuelle par membre de l'équipe

Ce besoin d'évaluer individuellement les membres de l'équipe est hérité principalement des modèles traditionnels de gestion des organisations.

L'agilité quant à elle, privilégie le travail en équipe. En partant du principe qu'une équipe pluridisciplinaire auto-organisée est capable de résoudre les problématiques auxquelles elle fait face et proposer des solutions.

Le nombre de Story Points par membre de l'équipe n'est pas en soi une information utile. Au contraire, elle instaure un culture individualiste dans l'équipe, chacun voulant se mettre en avant en montrant qu'il "livre" plus, en reléguant au second plan les choses les plus importantes à savoir l'entre-aide, la collaboration, la résolution des problèmes, la co-construction des solutions, la satisfaction de l'utilisateur ou client du produit, etc. Une telle équipe accomplira difficilement de grande chose. A l'instar d'une équipe de Foot qui réunit toutes les stars à chaque poste, sans jamais briller dans les grandes compétitions (je ne parle pas du PSG).

5. Prédire le futur avec les Story Points

Evidement on doit faire des projections (forecast). Evidement on doit appréhender les délais d'atterrissage et de livraison pour anticiper au mieux. Les Story Points peuvent se révéler utiles. Mais il ne faut pas tomber dans le piège de revenir au mode prédictif, l'opposé de l'agile qui se veut par définition empirique dans un environnement complexe et incertain.

Nous constatons une utilisation exagérée des Story Points de nos jours, avec des calculs et prévisions typiques d'un cycle de gestion en V, visant à être le plus précis possible. Ce qui suppose que tout un backlog doit être estimé de manière plus ou moins précise pour espérer obtenir un plan fiable. Les techniques d'estimation qu'on connaît (Extreme Quotation et autres), ne garantissent naturellement pas cela.

6. Communiquer des Story Points aux Stakeholders

Je n'appellerai pas celui-ci un anti-pattern. Je le déconseillerai quand même.

Les Story Points sont des fois mal compris par les équipes mêmes qui l'utilisent. Que dire d'une personne encore plus éloignée. Souvent ils ne comprennent pas ce que cela signifie.

Aux Stakeholders, parlez leur d'objectifs produits, d'objectifs de livraison, plan de livraison, objectifs de sprints, des epics et features. Des feedbacks et retours des utilisateurs. De la trajectoire à prendre sur le produit. Economisez leur des minutes d'explications pour comprendre ce que 30 points veulent dire. Souvent beaucoup de débats à faible valeur pour eux.

7. Evaluation annuelle sur base des Story points

Celui ci, que j'ai réservé pour la fin, est l'anti-pattern qui m'a le plus choqué de ma modeste expérience. Au vue de tout ce qui a été dit plus haut, imaginez qu'un développeur se voit refuser une promotion, une prime, ou qu'il soit évalué négativement, juste parce qu'il a à son compteur un faible nombre de points!

Ceci est révélateur de la culture et du niveau de maturité agile de cette organisation. Une Story à faible point pourrait être la Story qui révolutionne le produit, qui apporte plus de valeur aux utilisateurs, qui génère le plus de ROI sur le produit, etc.

Un tel système n'est pas sans conséquence. Aussi bien pour l'entreprise que pour le produit en question. Le besoin de sécurité des individus, surtout ceux qui en ont été victimes, les poussera à s'adapter à ce risque. Leurs efforts seront consentis sur comment sécuriser leurs revenues et leur évolution individuelle, plutôt que sur le succès du produit pour lequel cette équipe a été mise en place. Et beaucoup d'autres comportements contreproductifs.

Une réaction que j'ai vu dans une entreprise : des équipes qui divisent leurs user story, pas pour refléter les besoins du produit à construire, mais plutôt le niveau d'intervention des membres qui la constituent. Chacun donnant une estimation à "sa" story, pour mieux faire apparaitre sa "contribution" au moment des évaluations.

IV - Interrogations

Tous ces dysfonctionnements et anti-patterns révèlent quand même un besoin des entreprises d'évaluer la productivité et la performances des équipes agiles. La question à se poser c'est que dit l'Agile dans cela? Quoi mesurer et comment mesurer la productivité des équipes? Comment évaluer individuellement et collectivement l'équipe produit?

Tant de questions légitimes à se poser, auxquelles nous tenterons de répondre éventuellement dans un autre post.

V - Recommandations

Des recommandations, oui j'en ai quelques en effet :

La plus simple et la moins évidente : continuer à utiliser les Story Points

Malgré les nombreuses mauvaises utilisations, les Story Points restent un outil utile qui peut faciliter la collaboration dans une équipes agile.

Un grand Warning sur les anti-patterns. Impliquer au mieux le Scrum Master, le Coach Agile, de votre équipe ou d'une autre, voire même d'une autre entité de l'organisation. Quelqu'un capable de detecter ces anti-patterns et d'y apporter des réponses.

Si l'un de ces anti-patterns est en oeuvre dans votre cas, travaillez avec lui de sorte à rendre les conséquences visibles et comprises par tous. Prendre les décisions idoines. Tout faire pour y remédier et ainsi éviter les effets de bord.

Une alternative : Utiliser d'autre technique d'estimation relative

Il n'y a pas que les Story Points pour faire de l'estimation relative. Les tailles de chemise (XS, S, M, L, XL), ou d'autres techniques peuvent bien marcher.

La solution raccourci : revenir aux heures/jours

On peut bien faire de l'Agile, du Scrum ou autre, sans les Story Points. Rien ne vous y oblige. Si cela crée plus de problèmes qu'ils n'ent résolvent, retournons à la case départ, non?!

La cible : Ne pas estimer tout simplement

Cela semble irréalisable et irréaliste. L'expérience montre que c'est plus pragmatique et plus efficace de respecter les points ci-dessous:

• L'équipe se focalise sur comment découper le travail et en faire une unité la plus atomique possible.
  
  
• Se fixer des objectifs de sprints qui permettent de progresser vers les objectifs du produit.
  
  
• Privilégier les livraisons courtes. de sorte que le besoin de planification longue durée (donc d'estimation) se réduit au mieux.
  
  
• Utiliser certaines métriques de gestion de flux (throughput, cycle time, etc.) pour optimiser le circuit de production et de livraison, et éviter les pertes en cours de chaine et les goulots.
  
  

Plus de détails sur le #noestimate, GIYF :)