Accueil Nos publications Blog Arrêtez les estimations en points : Let’s Align !

Arrêtez les estimations en points : Let’s Align !

pourquoipointDe nombreux articles traitent du sujet des estimations mais, étant encore confronté chez mes clients à de nombreuses questions sur le sujet, je souhaitais rassembler mes réflexions ici.

Tout d’abord, je souhaite expliquer pourquoi nous faisons des estimations en points dans les contextes agiles. Mais avant tout, qu’est-ce qu’un point ? On parle aussi de Story point ou de point de complexité mais, dans cet article, j’utiliserai le terme de point.

 

Qu’est-ce qu’un point ?

Le point est une valeur qui renseigne de façon relative sur la complexité d’une chose à faire pour une équipe donnée à un instant donné. L’utilisation du point n’a donc de sens que :

  • si on a plusieurs choses à estimer
  • si on a une équipe pour réaliser l’estimation
  • mais surtout si on décide de réviser nos estimations de façon continue tout au long de la réalisation d’un produit

Mais alors, pourquoi utilise-t-on le point dans les contextes agiles ? Tout simplement parce qu’en tant qu’être humain, nous sommes mieux câblés pour réaliser des estimations relatives. Nous sommes tous capables de dire rapidement qu’un éléphant est plus lourd qu’un lion, par contre il nous est très difficile d’estimer de façon absolue le poids de ces deux animaux.

Toute la force de l’estimation relative réside dans le fait que celle-ci est plutôt rapide à réaliser pour nous. Par définition toute estimation est fausse, donc autant ne pas gaspiller notre temps précieux à sortir un chiffre extrêmement précis sachant que celui-ci sera faux. Par contre, on peut se rapprocher rapidement d’une estimation dont la marge d’erreur sera acceptable en utilisant les estimations relatives.

Et les abaques alors ?

abaquesSi on reprend l’analogie du poids des animaux, vous pourriez me dire : « Mettons l’éléphant ou le lion sur une balance et le tour est joué ! ». On obtiendra ainsi une estimation rapide et précise, reste juste à trouver une balance appropriée. C’est justement là qu’on touche à la limite de l’analogie. Vous connaissez, vous, une balance pour peser le poids d’une fonctionnalité, sa complexité ? Certains diront qu’il suffit d’utiliser des abaques, soit une sorte de table de correspondance qui permet facilement de dire que, tel type de fonctionnalité prendra tant de jours à réaliser pour une personne. Or, avec l’utilisation des abaques, il manque deux notions primordiales.

La première notion est le temps, ou si vous préférez, le moment où l’on fait l’estimation. Généralement, les abaques sont utilisés par le chef de projet pour réaliser l’estimation globale d’un cahier des charges en tout début de projet. Or, c’est le moment le plus incertain d’un projet. Souvent, on ne connait pas encore les membres de l’équipe, on ne sait pas si ces derniers arriveront à travailler ensemble efficacement, on ne sait pas si les connaissances techniques des équipiers seront à la hauteur pour couvrir l’ensemble des besoins et peut-être même que nous découvrons le métier de l’utilisateur du produit qu’il nous faut réaliser. Pourtant, devant tant d’incertitudes beaucoup s’évertuent encore à estimer précisément un besoin exprimé dans un cahier des charges plus ou moins détaillé. Pire encore, dans ce contexte, il est extrêmement rare de voir des projets revenir sur les estimations initiales sur lesquelles tout le monde s’est ancré.

L’autre notion manquante dans l’utilisation des abaques est la notion d’équipe. En effet, comme mentionné plus haut, les estimations sont généralement réalisées par le chef de projet alors que, parfois, l’équipe n’est même pas encore constituée. Par ailleurs, ces estimations sont généralement réalisées en jours-homme. D’ailleurs, faire les estimations en jours-homme à ce moment-là n’est pas vraiment un problème. Au contraire, le jour-homme est très facile à convertir en Euros pour évaluer le budget global d’un projet. Par contre, il ne faut pas se mentir, le chiffre qui sort à ce moment-là est plus qu’incertain. En effet, comme je l’ai mentionné précédemment, le début d’un projet est une phase où l’incertitude est extrême, et tant qu’on n’aura pas inventé la boule de cristal, il restera très délicat d’estimer le budget d’un projet sur la base d’un cahier des charges. Alors, une question fondamentale se pose : faut-il continuer d’estimer le budget de vos projets sur la base d’un cahier des charges ? La réponse la plus brève que je puisse donner est : « Si vos directions financières ne vous y obligent pas, arrêtez tout de suite de le faire ! »

Acceptons l’incertitude !

incertitudePour que votre projet agile soit bien mené, il est primordial d’accepter l’incertitude comme un paramètre clé de pilotage de votre projet. Cette incertitude étant principalement liée à l’extrême complexité inhérente à l’activité de développement logiciel.

Nous allons voir que la bonne utilisation du point peut vous aider à gérer cette incertitude. Tout d’abord, le point permet de prendre en considération les notions de temps et d’équipes occultées par l’utilisation des abaques.

En effet, les estimations en points sont réalisées « juste à temps » avec les connaissances du moment, dès que le besoin est prêt à être réalisé. Ainsi, on constate qu’un besoin qui peut paraître complexe au début du projet l’est beaucoup moins dès lors que l’équipe a gagné en connaissances sur les aspects métiers, humains et techniques. Finalement, un point en fin de projet peut nous permettre de faire plus de choses qu’un point en début de projet. Mais cette promesse n’est pas garantie, encore faut-il encourager la montée en compétence collective pour que l’équipe gagne réellement en connaissance.

Par ailleurs, les estimations en points sont réalisées par l’équipe sur la base d’un étalon qu’elle a défini par elle-même. En faisant ces estimations collectivement, nous allons favoriser l’engagement de l’équipe, qui va naturellement faire tout son possible pour réaliser les choses qu’elle aura elle-même estimée.

Pourquoi faire des estimations ?

pourquoi2A la base, les estimations en jours-homme sont faites pour gérer et suivre le budget des projets. Aujourd’hui, je rencontre certaines équipes qui ont remplacé le jour-homme par le point toujours pour gérer et suivre leur budget. C’est une erreur très (trop ?) classique. Le point n’est pas fait pour ça !

Cette erreur est probablement due au fait qu’on utilise le même terme d’estimation pour deux activités totalement différentes.

L’unité du jour-homme reste encore le meilleur indicateur pour suivre votre budget en relevant les jours consommés par les membres de votre équipe sur une période donnée. Il ne doit pas y avoir d’ambiguïté là-dessus.

Par contre, le point est une unité opérationnelle permettant de déduire la vélocité. La vélocité étant la somme des points terminés sur une période de temps fixe. Il s’agit d’un indicateur de prédictibilité du « reste à faire » à moyen et à long terme. Attention tout de même à garder en tête que cet indicateur de prédictibilité reste incertain. Par ailleurs, on a vu que les estimations en points étaient utiles pour gagner l’engagement de l’équipe à court terme.

Le point permet donc d’obtenir un indicateur de prédictibilité « incertain » à moyen et à long terme ainsi qu’un engagement de l’équipe à court terme. Je le répète donc, le point n’est pas fait pour gérer un budget !

Pour lever toute ambigüité, peut-être que les séances d’estimations collectives devraient s’appeler séances d’alignement. En effet, tout l’intérêt de cette pratique est de réussir à aligner tout le monde sur la compréhension, la faisabilité et la complexité du besoin exprimé.

J’ai dit plus haut qu’un des intérêts majeurs des estimations relatives était leur rapidité. Mais attention quand même à ne pas aller trop vite, l’intérêt de la pratique est de prendre le temps de la discussion pour que chacun puisse être aligné sur ce qu’il aura à faire. Parfois, je rencontre des équipes qui passent plus de temps à négocier le chiffre qu’à discuter du fond. Je leur rappelle que la valeur n’est pas dans le chiffre, mais plutôt dans la qualité des discussions générées.

Au début d’un projet les estimations peuvent donc prendre du temps, mais plus l’équipe va gagner en connaissance plus il lui sera facile de s’aligner. Généralement, on constate que les estimations (ou plutôt les séances d’alignement) deviennent de plus en plus rapides avec le temps.

Et le NoEstimate dans tout ça ?

noestimateParfois même, certaines équipes en viennent à faire du NoEstimate. Ces équipes ont acquis une telle maturité, qu’elles ont compris qu’il fallait avant tout s’aligner plus qu’estimer. Ces équipes ont déplacé l’effort d’estimation sur l’effort d’alignement et de découpage du besoin. Elles n’estiment plus, par contre elles s’alignent en permanence. Par ailleurs, ces équipes vont utiliser des mesures statistiques pour évaluer leur prédictibilité.

Il y a de nombreuses controverses autour du NoEstimate, la principale vient du nom volontairement provocateur de ce mouvement. Peut-être qu’un nom plus politiquement correct serait : #LetsAlign !

Conclusion

Pour en revenir au titre de cet article, si vous faites des estimations en points pour de mauvaises raisons, arrêtez tout de suite d’en faire. Cela ajoute plus de confusion qu’autre chose. Par contre, vous passerez à côté d’une pratique très utile pour gagner l’engagement de vos équipes et pour gagner en visibilité sur l’avancement de vos projets.

Il faut aussi garder en tête que cette pratique est également très utile pour aligner vos équipes sur ce qu’elles ont à faire pour réaliser un produit.

© SOAT
Toute reproduction interdite sans autorisation de la société SOAT