L'estimation agile : le guide complet
Un guide pratique de l'estimation agile : user stories, planning poker, story points, vélocité, et les techniques qui font leurs preuves lorsqu'une user story s'avère plus importante qu'elle ne le semblait au premier abord.
Les erreurs d’estimation prennent souvent des formes bien connues : des chiffres qui ont une signification différente selon les personnes, des réunions qui dépassent le temps imparti, des prévisions auxquelles personne ne se fie. La solution réside rarement dans une meilleure formule : il s’agit plutôt d’une vision commune à l’ensemble de l’équipe, et de considérer les estimations comme des prévisions plutôt que comme des engagements qui vous seront reprochés.
Ce guide passe en revue les éléments qui font leurs preuves dans la pratique : les user stories, le planning poker, les story points, la vélocité, ainsi que les techniques qui continuent de fonctionner lorsqu’une user story s’avère plus importante qu’elle ne le semblait au premier abord. Lorsque vous êtes prêt à réaliser une estimation avec votre équipe, utilisez TeamRetro : le planning poker avec vote privé, des jeux de cartes réutilisables et des points d’histoire finaux qui se synchronisent directement avec votre backlog.
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 une gestion stricte du temps.
Les « story points » mesurent 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 histoire 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.
Découvrez ce qu'est la vélocité d'une équipe dans une méthode agile, comment la calculer et comment planifier des sprints en fonction de celle-ci, ainsi qu'un calculateur de vélocité gratuit.
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 rapporte des points de récit, et pourquoi se concentrer sur le mauvais niveau rend la vélocité dénuée de sens.
Un guide pratique pour vous aider à choisir parmi les techniques d'estimation agiles : le « planning poker », les « story points », la méthode des tailles de t-shirt, l'estimation par affinité et la vélocité, ainsi que les cas dans lesquels il convient de les utiliser.
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 conformité d'une story, rédigé avant le début des travaux : ils précisent les formats valides, 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 « fausse tranche ».
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é, avec les versions incorrectes présentées à côté de leurs réécritures 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.
Qu'est-ce que le système de tailles « T-shirt » ? Comment animer une session ? Comment convertir les tailles S/M/L en points d'histoire ? Et dans quels cas le « planning poker » est-il la meilleure solution ?