Les 12 erreurs à éviter lors des séances d’estimation Agile

Cet article présente les 12 erreurs les plus rencontrées au cours des séances d’estimation sur des projets agiles. Même si le trait est parfois un peu forcé, ces situations sont tirées de faits réels et amènent à considérer une liste de bonnes pratiques.

1. Penser qu’une estimation est exacte

Au risque de décevoir certains d’entre-vous une estimation est, par définition, fausse.  Il ne faut pas confondre estimation et engagement. Pour ne pas se tromper sur un chiffrage, vous pouvez :

• Patienter jusque la fin du développement,
• Avoir déjà réalisé le même développement dans les mêmes conditions (équipe, client, technologie et fonctionnalité), ce qui n’arrive pour ainsi dire… jamais.

Deux choix s’offrent donc à vous : vous acceptez un chiffre probablement faux, mais fourni plus ou moins rapidement, ce qui donne au moins un ordre de grandeur OU vous attendez la fin du développement pour obtenir l’estimation la plus fiable.

2. Vouloir tout estimer en une seule fois

Au bout de 2 heures (et certains même avant), la majorité du groupe n’a qu’une seule envie : quitter la pièce ! (exceptés celui qui propose les User Stories et les 2-3 qui souhaitent en discuter). Il est préférable de mettre fin aux estimations dès lors que le niveau d’énergie du groupe commence à décliner (bâillements, moins de prise de parole, flirt avec le smartphone, signes de déconcentration, etc.).

Mieux vaut répartir plusieurs courtes séances d’estimation au cours d’une itération plutôt que de vouloir traiter l’intégralité d’une seule traite.

Evitez aussi les estimations au moment de la digestion !

3. Arrêter d’estimer quand on a atteint la vélocité

La vélocité a atteint 60 points lors des dernières itérations et vous venez d’estimer plusieurs User Stories pour un total de 61 points. Vous décidez donc de stopper la séance d’estimation et de traiter les autres User Stories lors de la prochaine itération.

Et si vous arriviez à réaliser les 61 points avant la fin de l’itération , dans quel stock piocheriez-vous la prochaine User Story, puisqu’aucune autre n’est estimée ?

Et si, au regard de leur coût (en points d’effort) par rapport à la valeur produite, le Product Owner décidait de déprioriser quelques-unes des User Stories (non déjà engagées dans une itération bien sûr), il vous faudrait replanifier une séance d’estimation pour une ou deux User Stories.

Et si le Product Owner venait à mettre fin de façon précipitée à l’itération en cours, le sprint suivant ne pourrait pas débuter tant qu’une nouvelle séance d’estimation n’ait eu lieu.

Les séances d’estimation étant timeboxées comme tout bon rituel agile, n’hésitez pas à utiliser l’intégralité du temps prévu pour poursuivre les estimations de vos User Stories. Vous vous constituerez ainsi un petit matelas de User Stories prêtes.

4. Ne pas respecter l’équilibre du temps de parole

Toute équipe est composée de personnes à tendance introvertie et des personnes extraverties. Certains sont peu bavards, alors que d’autres n’arrêtent pas de prendre la parole. Réaliser une estimation à plusieurs permet de prendre en compte l’avis de tous les développeurs du projet et non seulement des 2 ou 3 grands parleurs de l’équipe.

5. Passer plus de temps à expliquer une User Story qu’à l’estimer

Présenter les User Stories aux développeurs est un exercice difficile pour le Product Owner : la qualité rédactionnelle des User Stories est un facteur crucial, mais l’ordre dans lequel sont présenté les User Stories l’est tout autant.

Si 10 minutes d’explication du contexte sont nécessaires à chaque User Story pour une estimation qui prend 30 secondes, ne soyez pas étonnés que ce qui est développé ne correspond pas à ce qui a été rédigé.

Assurez-vous que les User Stories soient suffisamment comprises lors des séances d’affinage du Product Backlog. N’hésitez pas à compléter la User Story avec des commentaires explicatifs permettant d’en faciliter la compréhension. Ces actions aideront à fluidifier les séances d’estimation.

6. S’obstiner à estimer des Users Stories que l’on ne comprend pas

Après 2 ou 3 heures de planning poker, les participants n’ont plus l’énergie suffisante pour rester concentrer sur les estimations. Alors que le Product Owner continue de présenter ses User Stories, les développeurs ne font plus l’effort de comprendre et se contentent de répéter le même chiffre pour en finir.

7. Ne pas avoir 2 ou 3 repères pour les estimations

Lorsque l’on pratique des estimations en points, l’objectif est d’estimer par similitude en comparant chaque User Story par rapport aux autres. La meilleure façon de faire est de définir un étalon sur la base d’une User Story totalement connue de l’équipe et lui attribuer une valeur. Chaque User Story sera alors comparé par rapport à cet étalon, mais également de façon relative aux User Stories déjà estimées. Je vous recommanderais de définir 3 Users Stories de référence (de taille différente) pour réduire le biais lié à la suite exponentielle (si vous utilisez Fibonacci).

8. Changer d’étalon à chaque itération

Il y a toujours une bonne raison pour changer les User Stories de référence :

• l’équipe a été trop rapide,
• l’équipe a été trop lente,
• les nouvelles stories du backlog ne sont pas comparables avec nos stories de référence, etc.

Or, changer de repère à chaque itération vous empêche d’avoir une stabilité dans vos estimations. Je recommande néanmoins de les renouveler de temps à autre (à la fin de chaque version, au bout de X versions, etc.) pour que la comparaison se fasse sur des éléments récents, proches, que l’on ressent encore.

9. Retenir toujours l’estimation la plus élevée

Pour réduire les risques de pénalité, notamment dans des équipes soumises à engagement, il peut être tentant de retenir systématiquement l’estimation dont la valeur est la plus élevée, malgré une large dispersion des estimations individuelles.

Cette pratique, outre à l’origine de perte de confiance de la part du client, ne pousse pas les développeurs juniors à fiabiliser leurs estimations. Lorsque les estimations divergent, il est préférable d’ouvrir le débat pour permettre une convergence vers un consensus d’équipe.

10. Se forcer à estimer quand on en a aucune idée

Vous êtes développeur junior ou vous venez d’arriver sur un projet agile. Vous assistez à vos premiers planning pokers, mais vous n’osez pas dire que vous n’arrivez pas à estimer telle ou telle User Story. Vous le savez certainement, mais il est sûrement utile de rappeler qu’il existe une carte munie d’un point d’interrogation permettant d’annoncer clairement que l’on n’a aucune idée de l’estimation. L’intérêt est de permettre au Product Owner de préciser la User Story qu’il présente, voire de la décomposer plus finement.

 11. Penser que 1 point = 1 heure

Même s’il peut être tentant d’adapter la « Suite de Fibonacci » en considérant :
1 point = 1 heure, 2 points = 2 heures, 8 points = 1 journée…
ou : 1 point = 1 jour « idéal »
il est pourtant nécessaire de rappeler que les points de complexité / points d’effort n’ont pas d’unité.

Vous faites donc vos estimations soit en points soit en jour/homme mais vous ne mélangez pas les deux.

12. Déduire un ratio entre les points et les jours/homme

L’équipe a estimé le Backlog en points. Le manager (ou le chef de projet), quant à lui cherche à saisir ces données dans MS Project son logiciel de gestion de projet favori, afin de sortir un superbe diagramme de GANTT. Le logiciel de gestion de projet n’acceptant que des jours/hommes, une règle de 3 s’avère nécessaire et les 6 sprints de la release se retrouvent planifiées comme par miracle.

Bien évidemment, même si sur le long terme on peut faire émerger une relation entre les points et les jours/homme, cela ne sera jamais aussi précis qu’un simple ratio.

Si vous en arrivez-là, il vous reste la possibilité d’utiliser les tailles de T-shirt (XS, S, M, XL, XXL) pour estimer les User Stories.