L'estimation agile : le guide complet

Le « Planning Poker » est une technique d'estimation agile fondée sur le consensus : les équipes votent en secret, dévoilent toutes leurs cartes en même temps, puis discutent de l'écart entre les estimations jusqu'à ce que celles-ci convergent.

Comment animer une session de « planning poker » qui permette d'obtenir des estimations utiles sans s'éterniser : la préparation, le cycle en quatre phases, le choix d'un jeu de cartes et le respect strict des limites de temps.

Les « story points » permettent de mesurer l'effort relatif, la complexité et le degré d'incertitude d'un travail — et non le nombre d'heures. Comment évaluer l'ampleur d'un projet par rapport à une « story » de référence, et les questions qui posent problème aux équipes.

Les points de scénario augmentent de 1, 2, 3, 5, 8, 13, car l'élargissement des écarts traduit l'incertitude : l'échelle cesse de prétendre qu'il est possible de distinguer un 13 d'un 14. Voici pourquoi ces écarts sont essentiels.

Les points de story mesurent l'effort relatif ; les heures mesurent la durée — ce sont deux axes différents. Si vous établissez un tableau de conversion des points en heures, vous revenez en fait, sans vous en rendre compte, à une estimation du temps.

La vélocité correspond à la moyenne des points de story qu'une équipe réalise par sprint. À quoi sert-elle, pourquoi perd-elle tout son sens dès lors qu'elle devient un objectif, et comment s'assurer qu'elle reste fiable ?

Les gens ont du mal à estimer « combien de temps cela prendra-t-il ? », mais sont doués pour déterminer « est-ce plus important que cela ? ». L'estimation relative repose sur ce second principe — et c'est pourquoi les points de story fonctionnent.

Les premières estimations présentent un large écart parce que le travail est inconnu, et non parce que votre équipe ne sait pas bien estimer. Que signifie le « cône d'incertitude » et comment le réduire — et non l'élargir.

Les épopées, les récits et les tâches constituent trois niveaux, chacun comprenant trois fonctions. En quoi consiste chacun d'entre eux, lequel génère des points de récit, et pourquoi le fait de se focaliser sur le mauvais niveau rend la vélocité dénuée de sens.

Comparaison des techniques d'estimation agiles — le « planning poker », la méthode des tailles de t-shirt, la méthode des « buckets », le vote par points, l'estimation par affinité et l'estimation « magique », ainsi que les risques d'échec que chacune d'entre elles recèle.

Les erreurs récurrentes commises lors des sessions de Planning Poker — calcul de la moyenne des cartes, estimation en heures, utilisation abusive de la vélocité, inflation des points d'histoire — et comment y remédier.

Les critères d'acceptation constituent le test de réussite ou d'échec d'une story, rédigés avant le début des travaux : ils précisent les formats acceptables, fournissent des exemples concrets et indiquent en quoi ils diffèrent de la définition de « terminé ».

La définition de « terminé » consiste en une liste de contrôle à l'échelle de l'équipe que chaque story doit respecter avant sa livraison. Voici un exemple de cette définition, qui en est le responsable et en quoi elle diffère des critères d'acceptation.

La définition de « prêt » correspond à la liste de contrôle qui indique qu’une story est prête à être intégrée au sprint. Ce qu’une liste utile doit inclure, pourquoi la plupart sont ignorées, et la version qui constitue réellement un obstacle.

Une fonctionnalité dont vous ne pouvez pas évaluer le coût est généralement une fonctionnalité que vous ne pouvez pas encore livrer. Comment déterminer quand il faut la diviser, quelles sont les lignes de découpe qui permettent d'obtenir des parties livrables, et celles qui ne font que donner cette impression.

SPIDR propose cinq méthodes fiables pour diviser une user story : spike, chemin, interface, données, règles. Chaque ligne de découpage : quand elle fonctionne, et quand elle produit une tranche erronée.

Les découpages verticaux permettent de livrer de la valeur ; les découpages horizontaux permettent de livrer des engagements. Pourquoi le découpage par couche technologique retarde la création de valeur, et comment opter pour un découpage en fonction des résultats attendus par les utilisateurs afin de livrer quelque chose à chaque sprint.

Une « user story » est une promesse de valeur concise, formulée en langage clair. Le format « rôle-objectif-avantage », les trois « C », la liste de contrôle INVEST et les cas où les « user stories » ne constituent pas l'outil approprié.

Seize exemples d'histoires utilisateur couvrant l'authentification, le commerce électronique, les applications mobiles, les API et les bogues — chacun étant annoté, les mauvaises versions étant présentées à côté de leurs versions réécrites afin que la différence soit visible.

Le modèle classique d'histoire utilisateur avec une fiche « copier-coller », les variantes à connaître, ainsi qu'un exemple concret, du modèle aux critères d'acceptation, en passant par l'estimation.