Estimation relative de la taille (par exemple, en points de story)

Auteur : Dominik Maximini
Source : Estimating relative sizes (e.g. story points)
Date : 27/02/2014

---

Traducteur : Fabrice Aimetti
Date : 27/06/2016
Relecteur : Gaëtan Alet

---

Traduction :

Beaucoup d'entreprises se heurtent à des problèmes lorsqu'elles essayent d'estimer une taille de façon relative au lieu d'utiliser des nombres absolus (par exemple Points de Story vs Jours x Homme). Dans les formations Scrum, c'est généralement le concept le plus difficile à discuter. Très souvent, l'approche n'est pas bien comprise et les personnes retombent dans des comportements connus (estimation absolue). Ce billet a pour objectif d'expliquer ce qu'est l'estimation relative en tant que tel, sans rentrer dans les détails techniques (par exemple, le Planning Poker n'est pas expliqué). Si vous souhaitez aller plus loin, je vous conseille la lecture du livre de Mike Cohn : "Agile Estimating and Planning".

Pourquoi tout estimer ?

Dans Scrum, l'objectif de l'estimation n'est pas de prédire l'avenir de façon sûre. Il s'agit de comprendre clairement ce que le Product Owner veut. Il s'agit de collaboration et d'information. L'estimation en tant que telle est donc un produit dérivé. Oui, il est possible de prévoir la date de livraison et son contenu à l'aide d'estimations Agile si vous avez une équipe stable et une vélocité connue. Pourtant, la plus grande valeur repose dans le fait que l'équipe comprenne les souhaits du Product Owner et qu'elle soit désormais capable de prendre des décisions qui soient compatibles avec ces souhaits.

Pourquoi estimer de façon relative ?

Scrum ne vous force pas à utiliser les techniques d'estimation relative. Scrum est juste un cadre de travail (NdT : framework) qui vous permet d'utiliser n'importe quelle méthode d'estimation souhaitée. Cela inclut les nombres absolus comme les Jours x Homme ou même les Jours. Cependant, il y a trois bonnes raisons d'utiliser la taille relative.

1. Les personnes sont mauvaises lorsqu'il s'agit d'estimer de façon absolue, et bonnes lorsqu'il s'agit d'estimer de façon relative. Regardez les deux pierres ci-dessous et dites-moi : quelle grosseur fait la première et quelle grosseur fait la seconde (estimation absolue) ? Maintenant, dites-moi combien de fois la seconde pierre est plus grosse que la première (estimation relative). Généralement, les personnes sont plus rapides et meilleures avec la seconde question. Il est donc plus rapide et par conséquent moins coûteux d'utiliser des techniques d'estimation relative.

2. Les personnes ne débattent pas non plus autant lorsqu'elles estiment de façon relative ou lorsqu'elles estiment de façon absolue. Avez-vous déjà écouté deux personnes se disputer sur qui va réaliser le travail parce que cela va influencer l'estimation ? Vous y êtes.

3. Vous n'avez pas besoin de ré-estimer une taille relative à chaque fois que quelque chose change. Si vous estimez vos items en Jours et que quelque chose change (par exemple, vous perdez un développeur ou vous avez un nouveau framework), vous devez généralement ré-estimer le backlog en entier. Disons qu'il vous faut 5 minutes pour estimer un item, votre backlog contient 100 items, et 5 personnes sont impliquées dans le processus d'estimation : cela représente donc 5 jours x homme par séance d'estimation. Avec des nombres absolus, vous devrez réinvestir 5 jours x homme à chaque fois que quelque chose change. Alors qu'avec l'estimation relative, vous devrez juste investir une fois. A chaque fois que quelque chose change, l'estimation reste la même et la seule chose qui change est la vélocité. Cette vélocité est mesurée et non estimée, vous n'avez donc pas à dépenser votre argent pour la calculer.

Dans quelle unité estimons-nous ?

Il y a toujours débat sur l'unité à utiliser pour estimer de façon relative. Certaines personnes parleront de "complexité", d'autres parleront d' "effort", d'autres encore parleront d'autres choses. Vous pourrez chicaner sur les termes pendant des heures, si vous en avez envie. Cela ne vous rapprochera cependant pas de votre but. Tous les avis se valent ici. En réalité, l'unité utilisée importe peu tant que l'équipe se met d'accord. C'est toujours difficile lorsque vous choisissez de parler en effort puisque l'effort dépend d'une multitude de facteurs et cela correspond en fait quasiment à une technique d'estimation absolue. Vous vous épargnerez beaucoup des discussions inutiles en utilisant plutôt la "taille". La taille, c'est neutre, pas directement liée à l'effort, et vaguement liée à la complexité. Encore mieux : chacun a une compréhension partagée de ce terme.

Pourquoi utilisez les nombres de Fibonacci ?

La plupart des équipes Scrum utilisent une échelle de Fibonacci légèrement déformée pour estimer de façon relative. Fibonacci a trouvé une suite intéressante de nombres : chaque fois que vous additionnez les deux nombres précédents, vous obtenez le suivant dans la suite. Donc une suite de Fibonacci ressemble à ça : 1-1-2-3-5-8-13-21-34-55-89 et ainsi de suite. La plupart des équipes utilisent une suite similaire : 1-2-3-5-8-13-21-40-100. Les raisons sont simples :

1. Si vous demandez à un développeur la grosseur d'une chose par rapport à une autre, il vous répondra très souvent "deux fois plus gros". Avec Fibonacci, il n'y a pas "deux fois plus" et les personnes doivent prendre une décision. Certains chercheront le plus grand nombre, d'autres la plus petite valeur. La chose importante est le résultat de la discussion : soudain, les personnes ont besoin de déclarer la raison pour laquelle elles ont choisi un nombre. Comparer ces raisons peut conduire à une discussion qui clarifie de nombreux aspects pour les développeurs. La discussion constitue la vraie valeur du processus d'estimation.

2. Beaucoup d'équipes ne sont pas fidèles au vrai Fibonacci parce que les régions "34", "55" et "89" implique une certitude qui n'existe tout simplement pas. Déclarer "40" au lieu de "34" ou "100" au lieu de "55" véhicule un niveau de granularité qui reflète l'incertitude de ces régions. Pour parler simplement, l'équipe dit à son Product Owner en montrant "40" que "cet item est trop gros et qu'il doit être affiné" alors que "100" signifie en fait que "cela ne rentrera jamais dans un sprint, et qu'il est nécessaire d'affiner plus".

3. Plus les nombres sont gros, plus l'écart entre eux est grand. Cela permet d'illustrer le fait que les estimations deviennent moins fiables en faisant grossir la taille. Les nombres de Fibonacci sont excellents pour faciliter les discussions dans un contexte d'estimation.

Puis-je également utiliser différents types d'estimation ?

Bien sûr. J'ai déjà utilisé (en plus des points) jusqu'à maintenant les tailles de t-shirt (XXS to XXXL) et les animaux (fourmi, grenouille, ..., girafe, éléphant). Les tailles de t-shirt et les animaux aident à favoriser la compréhension que nous estimons en taille, et pas en effort. Quel est l'effort d'un éléphant ? Quelle est sa complexité ? Je ne peux pas le dire. Mais je peux estimer sa taille !

Comment l'estimation relative fonctionne-t-elle ?

J'aime expliquer l'estimation avec une image de quelques pierres. Imaginez que vous avez trois piles de pierres :



Soit une simple pierre de la première pile qui se voit affecter le nombre "2" (eh bien, c'est la plus petite pierre que nous voyons ici MAINTENANT, mais qui sait s'il n'y aura pas une plus petite pierre dans l'avenir ?). Maintenant, nous demandons à l'équipe la grosseur de la pierre dans la seconde pile par rapport à une pierre de la première pile. Les équipiers vont en discuter et revenir avec un nombre. Probablement "5" dans notre exemple. La même procédure s'applique pour une pierre de la troisième pile, qui va sans doute sortir à "13". Notez bien que nous n'avons pas à ce stade demandé ce que nous allons faire avec les pierres. Nous discutons juste de leurs tailles. Nous n'avons pas non plus discuté de qui se chargerait des pierres. Cela importe peu lors de l'estimation relative.

Comme vous pouvez le voir, nous avons dix pierres dans la première pile, trois pierres dans la seconde pile et deux pierres dans la troisième pile. Cela constitue notre "backlog" : 10*2 + 3*5 + 2*13 = 51.



Notre backlog total a donc une taille de 51. Cela a été facile, mais nous n'avons encore rien fait avec les pierres.

Imaginez que mon chef soit une personne méchante. Il me dit qu'il veut que je transporte toutes les pierres d'une extrémité de la ville à une autre à mains nues et sans aucun outil. Il me dit aussi de les ramener une fois que je les aurai toutes déplacées, nous avons donc un backlog infini. Nous tombons d'accord sur une durée de sprint de une semaine.

Je n'ai pas d'idée sur le temps que prendra le rapatriement des pierres. Il n'y a a donc pas de lien avec le temps. Lorsque j'ai commencé à transporter les pierres, cela m'a pris une semaine entière pour déplacer les pierres d'une extrémité à l'autre de la ville. J'ai donc déplacé dix petites pierres, trois pierres moyennes et deux grosses pierres pendant le sprint. Cela a donc donné une vélocité de 51 (la somme de toutes les tailles complètement déplacées pendant un sprint) pour le premier sprint.

Vélocité1 = 51

Mon chef m'a ensuite forcé à déplacer les pierres dans les deux sens chaque semaine. J'ai commencé à prendre du muscle. Ce n'était pas seulement génial mais cela a aussi augmenté ma vélocité puisque j'ai réussi à déplacer les pierres dans les DEUX sens en une semaine. J'ai donc déplacé vingt petites pierres, six pierres moyennes et quatre grosses pierres en un sprint. La nouvelle vélocité est de 102.

Vélocité2 = 102

La taille des pierres n'a pas changé parce que j'avais des muscles. Ce qui a changé c'est la vitesse à laquelle je les déplaçais.

Maintenant, imaginez que mon chef est dans un bon jour et m'autorise à utiliser les transports publics. Je réussis maintenant à déplacer toutes les pierres dans les deux sens deux fois par sprint, ce qui donne une vélocité de 204.

Vélocité3 = 204

La taille des pierres n'a pas changé parce que j'utilisais un nouveau framework "transports publics" ou parce que j'avais transporté tant de pierres dans les sprints passés. Ce qui a changé c'est ma vitesse à le faire.

Comme vous le voyez, je n'ai pas eu à ré-estimer la taille des pierres. Je n'ai pas non plus eu à estimer une seule valeur en temps, par exemple le temps que cela prend pour transporter une petite pierre d'un point A à un point B. L'aspect temporel rentre en ligne de compte lorsque vous combinez l'estimation des tailles avec la vélocité et la durée du sprint. Mon chef est donc capable de juger la quantité de temps que cela me prendra pour déplacer une certaine quantité de pierres à partir du moment où il connaît ma vélocité actuelle.

C'est également vrai dans le domaine du développement logiciel. Lorsqu'on estime les tailles de façon relative, il importe peu de savoir si vous avez déjà fait ce travail un millier de fois auparavant, si vous avez de nouveaux outils luxueux, si la personne est expérimentée ou inexpérimentée pour ce type de travail. L'estimation restera la même. Ce qui change c'est la vélocité. C'est tout.

Comment s'assurer que les personnes connaissent la valeur de référence de l'estimation ?

Certaines équipes estiment toujours par rapport au dernier sprint. Cela conduit généralement à une dérive sur la taille. Avec l'expérience, la taille des nouveaux items du backlog est réduite parce que les développeurs pensent implicitement en effort ("J'ai déjà réalisé ça auparavant donc ce sera plus facile, ce qui veut dire que ce ça ne vaut pas 5 mais 3 maintenant"). Cela mène à une chute de la vélocité au lieu de la faire progresser lentement. Même si ce n'est pas nécessairement mauvais, cela peut facilement être évité. L'important est de disposer d'une feuille de référence des estimations. Prenez juste une feuille de paperboard et notez toutes les catégories ( par exemple 1, 2, 3, 5, 8, 13, 21). A chaque fois qu'un sprint est terminé, demandez à votre équipe si l'un ou plusieurs des items de votre backlog ont été correctement chiffrés. Généralement l'équipe vous fournira certains items. Ils sont ensuite posés (sous forme de post-its par exemple) sur le paperboard près des nombres concernés. Chaque fois que l'équipe estime les nouveaux éléments du Backlog Produit, ceux-ci sont comparés à cette feuille de référence au lieu de prendre en compte les estimations du dernier sprint. De cette façon, les estimations restent constantes au fil du temps, mais la vélocité change. C'est ainsi que cela devrait être.

J'espère que cela vous aide lorsque vous essayez des techniques d'estimation relative. Faites du Scrum !