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.

Chapitre 1Qu'est-ce que le « planning poker » ?

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

Chapitre 2Comment animer une session de « planning poker »

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

Deux personnages représentés par des post-it, dos à dos, comparent leur taille à une marque sur le mur, ravis d'avoir déterminé lequel des deux est le plus grand.
Chapitre 3Que sont les « story points » ? Estimer l'effort, et non le 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 établir une comparaison avec une story de référence, et quelles sont les questions qui posent problème aux équipes ?

Chapitre 4Pourquoi les points d'histoire s'appuient-ils sur la suite de Fibonacci ?

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.

Chapitre 5Points de scénario ou heures : pourquoi leur conversion est un piège

Les « story points » 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 discrètement à l'estimation du temps.

Un personnage représenté par un post-it sur un tableau blanc trace une ligne traversant six colonnes de sprint, en indiquant la partie centrale, plus stable, plutôt que le pic le plus élevé.
Chapitre 6La vélocité d'équipe en agile : comment la mesurer et l'exploiter (+ calculateur gratuit)

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.

Chapitre 7Estimation relative ou absolue (et pourquoi la relative l'emporte)

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.

Chapitre 8Le « cône d'incertitude » dans l'estimation agile

Les premières estimations présentent un écart important parce que le projet est encore méconnu, 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.

Chapitre 9Épic, story et tâche : explication de la hiérarchie agile

Les épopées, les récits et les tâches constituent trois niveaux, chacun comprenant trois rôles. En quoi consiste chacun d’entre eux, lequel génère des points de récit, et pourquoi se concentrer sur le mauvais niveau rend la vélocité insignifiante.

Un personnage sous la forme d'un post-it qui s'éloigne d'un mur recouvert de notes entassées, se demandant laquelle il va redimensionner.
Chapitre 10Techniques d'estimation agiles : laquelle choisir et dans quelles circonstances ?

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.

Chapitre 11Erreurs et anti-modèles liés au Planning Poker

Les erreurs récurrentes qui peuvent survenir lors des sessions de Planning Poker (moyenne des cartes, estimation en heures, « vitesse » utilisée à mauvais escient, inflation des points de story) et comment y remédier.

Chapitre 12Critères d'acceptation : comment les rédiger

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 en quoi ils diffèrent de la définition de « terminé ».

Chapitre 13Dé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 « DoD », qui en est responsable et en quoi elle diffère des critères d'acceptation.

Chapitre 14Définition du terme « prêt »

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

Chapitre 15Fractionnement des user stories qui ne peuvent pas être intégrées à un sprint

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 l'illusion d'une livraison possible.

Chapitre 16Fractionnement des récits SPIDR

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

Chapitre 17Découpage horizontal ou vertical

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 garantir une livraison à chaque sprint.

Chapitre 18Qu'est-ce qu'une « user story » ?

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 dans lesquels les « user stories » ne constituent pas l'outil approprié.

Chapitre 19Exemples d'histoires utilisateur : 16 histoires annotées, les bonnes et les mauvaises

Seize exemples de user stories annotées dans 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 clairement visible.

Chapitre 20Modèle d'histoire utilisateur et critères d'acceptation

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.

Des personnages représentés par des post-it, portant des t-shirts sur lesquels est indiquée leur taille, sont alignés sous une carte de tâche afin de la mesurer ensemble.
Chapitre 21La méthode « T-shirt » dans le cadre d'une approche agile : comment cela fonctionne et quand l'utiliser

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 ?