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 complexe qu'il n'y paraissait.
Les erreurs d’estimation reviennent souvent sous des formes bien connues : des chiffres qui ont des significations différentes selon les personnes, des réunions qui dépassent le temps imparti, des prévisions auxquelles personne ne fait confiance. La solution réside rarement dans une meilleure formule. Il s’agit plutôt d’une compréhension 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 volumineuse 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 à bulletin 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.
L'estimation en points de story permet d'évaluer l'effort relatif, la complexité et l'incertitude d'un travail, et non le nombre d'heures. Comment évaluer un travail 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. Il s'agit de deux axes différents. Si vous établissez un tableau de conversion des points en heures, vous revenez en fait, sans vous en rendre compte, à l'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 cette seconde approche, 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 est incapable d'estimer correctement. 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 concentrer sur le mauvais niveau rend la vélocité dénuée de sens.
Un guide pratique pour choisir 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 qui peuvent survenir lors des sessions de Planning Poker (calcul de la moyenne des cartes, estimation en heures, « vélocité » utilisée à mauvais escient, 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 : les formats valides, des exemples concrets et la manière dont ils diffèrent de la définition de « terminé ».
La définition de « terminé » (DoD) correspond à une liste de contrôle que chaque story doit satisfaire avant sa mise en production. Exemples de listes de contrôle, comment rédiger la vôtre, et comparaison entre la DoD et les 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 estimer 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 de « user stories » annotées couvrant les domaines de l'authentification, du commerce électronique, des applications mobiles, des API et des bogues, les versions incorrectes étant 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 ?
Comment l'estimation par affinité permet d'évaluer l'ensemble du backlog en une seule session : les étapes du tri silencieux, dans quels cas cette méthode est plus efficace que le « planning poker », et comment la convertir en points de story.