Story point : ce n'est pas de la charge

Tout le monde ou presque connaît la technique des estimations en points.

On a beau expliquer et réexpliquer le pourquoi du comment, les organisations disent avoir compris mais retombent rapidement dans les réflexes pavloviens d'estimation de charge. Vous savez la bonne vieille "charge", en Hommes.jours ou Hommes.heures ? De plus, je ne suis même pas certain que les "experts" soient bien d'accord sur la bonne utilisation des story points. Je vous livre ici la mienne. Une chose est claire, les points servent à calibrer des itérations de production.

Je n'ai rien contre l'estimation de charge, mais ce n'est pas la même chose. Le "story point", autrement appelé "point d'effort" ou "point de complexité" représente une convention d'équipe pour désigner une catégorie de poids d'un élément à réaliser (user story). Explorons quelques différences :

  • les points n'ont pas d'unité. Ainsi les équipes peuvent convenir d'un modèle de points qui leur est propre : effort, complexité, risque etc. On pourrait ici disserter sur la différence entre effort et complexité, par exemple qu'un item pour être complexe pour un effort moindre ou inversement, mais ce n'est pas l'important. L'important est la convention en équipe. Récemment, une équipe hésitait sur sa représentation du point. Elle a finalement choisi que la dépendance avec des acteurs tiers en dehors de l'équipe pouvait représenter une sorte de complexité. Il n'est ici nullement question de charge. La raison d'être d'une estimation en point est la comparaison à une autre estimation en points (qui est d'autant plus fiable si l'"autre" a déjà été réalisé). Quand vous projetez d'acheter une maison, comment procédez-vous, ci ce n'est de comparer son prix à d'autres, similaires en termes de qualités ?

  • les points sont une estimation d'équipe, pas individuelle. En ce sens, l'estimation représente une complexité "nominale", et non pondérée par les compétences d'untel Si une personne est moins expérimentée, on préférera être prudent sur la vélocité de l'équipe que de changer l'estimation de l'élément. Sinon cela rendrait plus difficile des comparaisons ultérieures.

  • les points assument l'approximation inhérente aux exercices d'estimation. C'est d'ailleurs pourquoi on propose une suite de Fibonacci car cela oblige à trancher sur des catégories. Il est important de distinguer un poids de 1 ou de 2 mais que nous importe que l'élément soit de 20 ou 21 points ! Avec les charges, on se ment car on pense pouvoir prédire l'avenir au jour près en passant du temps à employer des modèles de projection plus ou moins complexe. On gagne ainsi du temps !

  • les points abstraient la notion temporelle. C'est voulu. Cela aide les coéquipiers a se poser de nouvelles questions , plus simples et plus efficaces dans les faits ("est-ce plus gros ou plus petit que"). Cerise sur le gâteau, il n'est pas exclu que cela diminue la pression sur les coéquipiers induite par les jours ou les heures. Enfin, avec les jours ou les heures, on peut être vite tenter d'y associer des délais. Or les problèmes fréquents dans les organisations sont les interruptions du travail qui rendent cette analogie plus que périlleuse (les délais sont un excellent moyen de piloter mais c'est une autre histoire... voir Kanban)

  • avec les points, on met davantage l'accent sur le terminé. Cette notion va de pair avec la "définition de fini". Ainsi, on peut faire confiance aux points pour l'avenir car on projettera un passé factuel sur un futur avec des choses vraiment terminées

Voila pour l'essentiel.

Pour finir, je pense qu'introduire cette pratique dans les organisations a le mérite de remettre en question notre arrogance à se dire capable de prédire l'avenir précisément, et d'aller vers plus de simplicité dans nos comportements (une des valeurs clef de l'agilité). En effet, lorsqu'une pratique simple et rapide suffit à atteindre le niveau d'incertitude d'une estimation, pourquoi s'évertuer à revenir à des usines à gaz ? C'est pourtant encore le cas dans de nombreux contextes, qui adoptent cette pratique mais n'abandonnent pas leurs fausses croyances. Il en résulte d'interminables débats sur la conversion points/jours, sur le lien avec la gestion budgétaire et j'en passe. Ces questions sont légitimes et il convient d'y répondre pour faire le pont entre l'ancien et le nouveau monde. Vous trouverez facilement les réponses dans le bon sens. Ne cherchez pas les nœuds aux cerveau et rappelez-vous à quoi cette pratique est destinée.

Les difficultés que vous éprouvez avec l'adoption de cette pratique révèlent peut être un problème d'une toute autre nature chez vous.

Simplicité ou pas ?

Merci pour votre lecture. A bientôt.

Commentaires

En réponse à Caro sur LinkedIn

Elle:

Merci David Brocard pour cet article sur la notion d’estimation et de points. Le réflexe pavlovien dont tu parles réside peut-être dans le fait que la passerelle n’a pas été trouvée entre cette estimation et les contingences budgétaires de l’entreprise ?

Moi:

Hello miss!

Oui. Mais plus exactement, on cherche la complexité là où il n'y en a pas.

Qu'est-ce qu'un budget (pour simplifier en jours) ? Ce n'est ni plus ni moins que la somme totale du temps de présence estimé d'un nombre de personnes assignées sur un projet (et qu'on paye pour ça).

Prédire cette quantité est par nature très difficile. Qui compte les interruptions lors de la journée, tout aussi difficile à évaluer ? Si les entreprises évaluaient le "facteur de focalisation" ("focus factor" = ratio du temps effectivement passé à produire sur le temps de présence sur le projet) de leurs salariés, elles seraient catastrophées ! Je l'ai souvent constaté de l'ordre de 50%...

Les points comptent plutôt des productions terminées, donc plus réalistes dans l'exercice de projection. S'il faut prendre une règle de 3 pour convertir un total de points projetés en budget, je n'y vois pas d'inconvénient. D'ailleurs, il ne semble pas y avoir 36 solutions. Mais compte tenu de la nature d'un point (voir mon post), l'opération est donc teintée d'une approximation non négligeable (ex: notion de complexité incluant les interactions avec l’extérieur)

C'est la même chose en projetant un nombre d'itérations, car ce n'est jamais qu'une somme de points (vélocité) dans un segment de temps. J'aurais tendance à préférer cette méthode, car elle assume encore plus l'approximation inhérente à l'exercice. On a un équipe de tant de personnes, elle estime qu'elle a encore besoin de tant d'itérations, qu'on multiplie par le temps de chaque coéquipier sur le projet. Point.

Ce que je dénonce, c'est l'hypocrisie de vouloir associer à des points une précision qu'ils ne peuvent pas avoir par définition. Les budgets sont précis, mais seulement une fois constatés. Le futur est imprécis, c’est tout.

J'adore cette pratique, car c'est un fabuleux biais pour les entreprises pour comprendre qu'on perd beaucoup de temps sans intérêt sur les estimations. Et au moins le débat est lancé, la possibilité d’une nouvelle culture peut émerger.


C’est comme les fameux « contrats agiles ». Il n’y pas vraiment de solution. Si on voulait être honnête, on reconnaitrait aisément que la vraie agilité se conclue simplement en T&M à travers la construction durable une relation de confiance. Le contrat en bande passante est le premier pas vers une prise de conscience, du fait de l’abandon de périmètre fixe. Mais dans les faits, il ne résout pas les tensions entre client et fournisseurs. On revient toujours à la guéguerre de l’étalonnage du point, de la « Definition de Prêt » qui prend des proportions démesurées. La encore ma préférence irait plutôt au prix à l’itération, car ça limite les débats stériles sur les détails.

Selon moi, tout cela ne fait que révéler le manque de lâcher prise qui caractérise le monde de l’entreprise.

D’où les réorientation massive du mouvement sur les aspect culturels.

« Collaboration > Contrat ». Et bien… Allons-y !