Estimations et Story points

Que l’on démarre sa transformation Agile ou que l’on soit déjà une équipe expérimentée, une même question revient encore et toujours : Qu’est-ce que c’est vraiment un story point ?
Après tout, on nous dit d’arrêter de compter les jours-homme pour compter des points. Est-ce que ça veut dire qu’on n’a plus le droit de raisonner en « temps à passer » ? Que doit-on alors « mesurer » ?

Cet article est basé sur l’excellent travail de Mike Cohn à ce sujet et a pour but d’apporter une réponse à cette question. Et nous allons vous vendre la mèche dès le départ : le story point c’est… un point d’effort !
Un point d’effort et non de complexité comme beaucoup le croient. Reste à savoir ce que c’est que l’effort…

Lorsqu’on commence à parler d’estimations, les premières questions qui émergent sont souvent les mêmes : Pourquoi estimer ? A quoi servent les estimations ?
C’est en comprenant d’abord pourquoi nous avons besoin d’en faire, que nous comprendrons mieux leur nature et celle des fameux story points.

Pourquoi ? A quoi servent les estimations ?

Prenons cette question en nous plaçant dans le cadre d’un projet informatique ou industriel.

Nous apprécions particulièrement la remarque de Mike Cohn qui va droit au but : la question clé qu’on entend encore et toujours dans la bouche des parties prenantes, des clients ou du management, c’est « Combien de temps ça prend ? », « Quand est-ce que ça sera fini ? ». C’est avant tout à ces questions que nous cherchons à répondre en planifiant sur la base d’estimations, c’est-à dire en essayant de prédire quelle quantité de travail sera terminée pour telle date, ou à quelle date nous pourrons livrer une première version du projet.

En plus de répondre à cette question fondamentale, estimer et planifier de façon itérative et incrémentale garantit que l’entreprise fait les bons choix de développement produit et maximise la création de valeur, notamment en permettant de :

• Réduire et contrôler les risques
  Les discussions qui ont lieu lors de l’estimation mettent à jour les zones d’ombre et les potentiels risques du projet. Il est ensuite possible de choisir comment traiter chacun de ces risques : faire des investigations pour gagner en connaissance et éliminer le risque, le prendre en compte dans la planification en prévoyant du temps supplémentaire…
• Réduire la part d’incertitude inhérente à tout projet
  Au cours de la réalisation du projet, l’équipe va acquérir de la connaissance. Celle-ci peut être prise en compte dans la planification Agile car elle est itérative : les estimations et la vision de départ qui comportaient beaucoup d’inconnues vont être affinées au fur et à mesure des itérations.
• Servir de support à la prise de décision et à la priorisation
  Comment décider si un projet ou une fonctionnalité particulière vaut le coup d’être réalisé sans avoir d’estimation de son coût ? Pour s’assurer qu’une entreprise investit dans les projets qui ont le plus de valeur, elle doit pouvoir estimer son potentiel retour sur investissement.
  Et une fois le projet lancé, afin d’être Agile, il est nécessaire de prendre très régulièrement toutes sortes de décisions et surtout de faire des compromis. Comment prioriser les fonctionnalités et plus largement la travail à faire, c’est-à-dire le backlog ? Si le projet prend finalement plus de temps que ce qui était prévu au départ, faut-il privilégier la date (par exemple s’il faut être présent à un événement ou prendre de vitesse un concurrent), ou le périmètre ? Quel compromis faire entre ces deux paramètres ? Faut-il allouer plus de budget à tel projet pour recruter deux testeurs supplémentaires ? etc.
  Piloter un projet Agile nécessite de constamment prendre de telles décisions et pour cela de pouvoir se baser sur des données factuelles telles que les estimations.
• Établir la confiance
  La confiance entre les différents acteurs, clients, décisionnaires, équipe, product owner, repose avant tout sur la capacité à livrer de façon fiable ce qui a été promis. Pour cela, il est souvent nécessaire de faire des compromis ou d’opérer un changement de cap que les clients ou les décisionnaires internes sont souvent réticents à décider. Des estimations provenant directement de l’équipe sur le terrain permettent d’apporter de la transparence sur le projet et de faciliter les discussions difficiles.
• Aligner l’équipe et partager l’information
  Les estimations permettent, au sein de l’équipe, de s’assurer d’une compréhension commune du périmètre, de la valeur à produire et de se mettre d’accord sur une même unité de mesure de la « taille » d’une fonctionnalité.
  Elles permettent également de partager un plan précis avec le reste de l’entreprise ou le client. Plutôt que de communiquer uniquement sur une date de sortie en leur demandant de nous croire sur parole, nous pouvons leur partager les données qui nous amènent à cette prédiction et également communiquer plus facilement sur les causes d’un changement par rapport à une prédiction initiale (par exemple si l’on découvre en court de route que la gestion de la nouvelle base de données est bien plus longue que ce qui était prévu au départ).

Que sont vraiment les story points ?

Les estimations servent avant tout à répondre à la question « Quand ? » . On parle donc bien d’estimations en temps et les story points sont une forme d’unité de mesure de ce temps.
Alors pourquoi ne pas tout simplement compter en heures ou en jours ? Pourquoi vouloir s’affranchir des fameux jours-homme ? Pour répondre à cette question, nous allons nous intéresser à l’effort.

Qu’est-ce que l’effort ?

Imaginons que nous faisons partie d’une équipe de coureurs dont le capitaine est Usain Bolt. Il est clair que nous n’avons pas le même niveau en course à pied et donc ne courons pas tous à la même vitesse. Par conséquent, si nous devons répondre tous ensemble à la question : « Combien de temps vous prendra cette course ? » , nos réponses seront très différentes et nous aurons bien du mal à nous mettre d’accord. Je pourrais par exemple estimer que la course me prendra 40 minutes alors que Usain Bolt annoncera 20 minutes.

De plus, si on ajoute à cela que notre équipe ne sait pas à l’avance qui sera disponible pour courir cette course, il nous devient impossible de prédire le temps que nous ferons. Prendre la moyenne de nos différentes estimations ne serait pas satisfaisant : cela nous demanderait beaucoup de concertation et de calculs pour arriver à un résultat qui serait, de toute façon, faux. En revanche, la distance à parcourir est une valeur commune à tous. En effet, nous pouvons tous nous mettre d’accord sur la distance à parcourir pour cette course, disons 5 kilomètres. Et si demain, nous devons faire des prédictions pour une autre course, par exemple 10 kilomètres, nous pouvons tous facilement nous accorder sur le fait que cela représente le double de la première course de 5 kilomètres.

De la même façon, les story points permettent aux équipes de s’accorder sur la taille relative des user stories. Là où estimer en jours-homme, va les forcer à se poser la question « Qui ferait la tâche ? ». La story 1 représente 3 fois plus d’effort que la story 2, et ce, même si le temps réel de réalisation varie en fonction des membres de l’équipe. En résumé, on choisit de faire une estimation relative plutôt qu’absolue.

Estimer l’effort de manière relative a une seconde vertu : prendre en compte l’imprécision. Faire des estimations n’est, par essence, pas précis puisqu’il est impossible de prévoir l’avenir.
Les êtres humains sont meilleurs pour réaliser des estimations relatives que des estimations absolues. C’est plus simple. Par exemple, si je vous demande d’estimer la quantité d’eau dans le verre ci-dessous, c’est difficile. En revanche, si je vous demande d’estimer cette quantité par rapport à celle d’un autre verre pour déterminer si elle est équivalente, supérieure ou inférieure, cela devient plus facile et naturel.

Pourquoi perdre notre temps et notre énergie à tenter d’estimer précisément le temps que prendra chaque tâche d’un projet dès lors qu’on admet que le résultat sera de toute façon vraisemblablement faux ? Les estimations relatives, plus grossières, sont nettement suffisantes étant donné la marge d’erreur. Elles nous fournissent d’abord un ordre d’idée de la taille d’un projet et cette vision s’affinera ensuite progressivement lors des phases de réalisation. Autrement dit, on apprend à partir de données réelles et cela nous permet de préciser nos plans.
Avec les story points, on utilise d’ailleurs le plus souvent une suite inspirée de la suite de Fibonacci : 1, 2, 3, 5, 8, 13, 20, 40, 100. Cette suite propose des valeurs de plus en plus éloignées les unes des autres, donc des estimations de plus en plus imprécises lorsque la valeur augmente. Cela permet de prendre en compte que plus un projet est important, plus il devient difficile à estimer.

Notons pour terminer qu’il est possible au début d’un projet d’utiliser des macro estimations, par exemple en utilisant des tailles de T-shirt (XS, S, M, L, XL) pour comparer des epics ou des features entre elles.

Effort versus complexité, risque et inconnue

On parle bien d’effort et non pas de complexité, de risque ou d’inconnue. Ces facteurs vont influencer l’effort estimé mais ne sont pas suffisants en eux-mêmes pour estimer le temps.

Nous allons reprendre l’exemple très parlant proposé par Mike Cohn. Imaginons que nous avons une équipe de deux personnes composée d’un chirurgien du cerveau et d’un enfant. Nous avons deux stories à réaliser : une opération du cerveau courante et coller 1000 timbres sur 1000 enveloppes. Nous supposons ici que les deux activités prennent autant de temps. Si vous estimez ces deux stories en fonction de leur complexité, l’opération du cerveau aura une estimation beaucoup plus élevée que l’affranchissement des enveloppes. Pourtant, si votre but est de planifier et de savoir quand l’équipe aura terminé, étant donné que le temps de réalisation est quasiment le même, l’estimation devrait être la même. En fait, on peut dire que si la complexité varie, l’effort à fournir dans les deux cas est comparable (bien que l’une nécessite une grand concentration et une grande dextérité, alors que l’autre nécessite surtout de la patience).

Voici un autre exemple pour illustrer le facteur risque. Vous devez estimer la durée pour vous rendre de chez vous à votre lieu de travail. Vous disposez de deux moyens de transport : le bus (rapide mais risqué car il y a souvent des bouchons) ou le vélo (sûr mais lent). Une estimation en « points de risque » vous donnerait un coût beaucoup plus élevé pour le bus. Pour autant, rien ne dit que vous rendre demain au travail en vélo sera effectivement plus rapide.

Nous le voyons bien, pour répondre à votre client ou décisionnaire impatient qui demande « Quand ? », c’est bien la notion d’effort et non de risque ou de complexité qui importe.
En résumé, le point d’effort doit prendre en compte la quantité de travail à fournir, la complexité, le risque et les inconnues.

Comment estimer ?

Cette partie sera détaillée dans un prochain article : Comment démarrer avec les story points ?

Nous nous contenterons dans cet article de vous donner quelques conseils :

• Pour avoir une base de comparaison commune à tous et stable dans le temps, utiliser un étalon (ou « baseline », c’est-à-dire un groupe de stories de références)
• Pour faciliter des estimations relatives, utiliser les story points avec une suite de type Fibonnacci, ou des tailles de T-shirts qui pourront ensuite être converties en points pour une approche plus macroscopique (pour des grandes fonctionnalités par exemple)
• Pour faciliter l’atelier d’estimations de l’équipe et s’assurer que chacun donne son avis sans se censurer, utiliser l’atelier de planning poker ou de magic estimation.
• Faites l’atelier d’estimation avec tous les membres de l’équipe, quelle que soit leur spécialité, car la discussion qui l’accompagne est aussi importante que le résultat.

Comment piloter un projet avec des story points ?

Il y aurait bien sûr beaucoup à écrire sur ce sujet ! Des livres lui sont d’ailleurs consacrés, par exemple, Agile Estimating and Planning de Mike Cohn.

Nous nous contenterons ici de vous rappeler les bases d’une planification de projet utilisant les points d’effort :

• Mesurer la vélocité de l’équipe à chaque fin de sprint afin d’adapter votre planification à la réalité tout au long du projet.
• Visualiser la quantité de travail à faire en comparaison de la vélocité à l’aide d’un burn down/up chart afin de vous projeter sur une date de fin de projet raisonnable.
  La mise à jour régulière de ce graphique, à chaque fin de sprint, vous permettra de réagir au plus vite si les choses dérapent.
• A partir de votre burn down chart, si vous constatez que la date de livraison espérée initialement apparaît intenable, agissez et réduisez le périmètre de la livraison pour conserver la date ou bien décalez la date.

Les erreurs à éviter

Nous vous proposons un petit aperçu des erreurs récurrentes avec les story points :

La conversion story point – jour-homme.

L’équipe indique bien un nombre de points d’effort sur chaque story, mais elle utilise tout simplement une règle de trois pour convertir des estimations en jour-homme vers les story points. Les estimations en jour-homme créent une complexité inutile et tuent le principal avantage des estimations en points : permettre à des personnes travaillant à des vitesses différentes de se comprendre et de se mettre d’accord. L’utilisation des points d’effort devient donc complètement factice et n’a plus aucun intérêt à part de s’exercer au calcul mental…

Le story point est un point de complexité.

C’est sans doute l’erreur la plus commune. L’équipe n’estime les user stories qu’en fonction de leur complexité. Elle va donc systématiquement sous-estimer les stories peu complexes mais demandant beaucoup d’effort (par exemple nécessitant beaucoup de test manuel). Cela va engendrer de fausses prédictions et un manque de visibilité sur la quantité de travail à réaliser dans le backlog.

Pas d’user stories de référence… les estimations dérivent dans le temps…

L’équipe n’a pas d’user stories de référence (ou « baseline »). Au fil du temps, ses estimations se décalent. La vélocité et le burn down chart ne sont plus fiables et ne permettent plus de faire de bonnes prévisions. Ils ne seront plus non plus des indicateurs fiables pour mesurer l’amélioration continue de l’équipe.

Prendre les estimations comme une planification précise et gravée dans le marbre.

L’équipe et/ou les parties prenantes confèrent aux estimations en story points une valeur de contrat. Si la vélocité est de 30 points et que le backlog contient 295 points alors l’équipe devra livrer dans dix mois. Cela ne peut pas fonctionner puisque l’art de l’estimation est par définition imprécis et inexact. La prédiction des dix mois devra être revue régulièrement en fonction des nouvelles découvertes, des variations de la vélocité et de l’affinage des estimations.

Prendre les story points comme une mesure de la productivité des équipes ou pire des développeurs.

Le risque est de voir apparaître de graves dérives (bien souvent inconscientes). Par exemple, des équipes surestimant les stories pour « gonfler » leur vélocité, ou se sous-engageant sur leurs sprints pour s’assurer de parvenir à les terminer, ou encore des développeurs faisant des horaires interminables ou bâclant la qualité de leur code afin de ne pas passer « trop » de temps sur une story qui a été estimée petite.
Les estimations en points d’effort ne sont en aucun cas à utiliser pour exercer un contrôle sur l’équipe, ou sur un développeur en particulier !

Se forcer à estimer quand on n’a aucune idée de ce qu’il faut réaliser.

L’équipe s’obstine à estimer sans comprendre le fonctionnel et sans avoir aucune idée de comment l’implémenter.

Conclusion

Le story point est un concept « faussement » simple et mal interprété par beaucoup d’équipes Agiles. Ces dernières le définissent souvent comme un point de complexité au lieu d’un point d’effort ou passent à côté de la notion d’estimations relatives plutôt qu’absolues.
Pour expliquer à votre équipe un point d’effort, pensez à utiliser des métaphores plutôt que des explications compliquées et relisez bien la liste des erreurs à éviter. Si vous constatez qu’elle a encore du mal à s’approprier les story points, n’hésitez pas à faire un serious game comme celui-ci : Chiffre-moi un avion.

Le sujet des estimations dans un projet Agile provoque beaucoup de débats et de controverse. Nous avons choisi de présenter l’approche d’estimations en story points qui, lorsqu’elle est bien utilisée, se révèle un très bon outil pour faire efficacement des estimations pertinentes avec le bon niveau de précision. Sachez cependant qu’il existe d’autres approches notamment le mouvement No estimates et l’approche par le débit.

Références

De nombreux articles sont disponibles sur le blog de Mike Cohn : https://www.mountaingoatsoftware.com/blog.