Estimation et planification agiles : points, vélocité et prévisions

Toute estimation est une affirmation sur un travail que personne n'a encore fait, formulée par des gens qui apprendront en cours de route des choses qu'ils ne peuvent pas savoir à l'avance. Ce n'est pas un manque de professionnalisme ; c'est la nature même de la situation. L'estimation logicielle est difficile parce que l'essentiel de l'effort consiste à découvrir quel est vraiment le problème, et cette découverte ne se fait qu'en construisant.

Le but utile n'est donc pas l'exactitude. Il s'agit de produire des prévisions assez honnêtes pour décider, assez peu coûteuses pour valoir le temps qu'on y passe, et exprimées de façon à conserver l'incertitude plutôt qu'à la masquer derrière un chiffre unique et assuré. Ce guide présente les techniques qu'utilisent les équipes agiles, la manière de prévoir une release sans faire semblant, et ce que l'argument du « no estimates » a de juste. La planification classique par réseau, qui répond à un autre problème, est traitée dans la gestion des délais.

Pourquoi les estimations sont incertaines

Trois sources d'erreur distinctes se cumulent.

La méconnaissance du problème. Les exigences telles qu'elles sont formulées ne sont jamais qu'une approximation du besoin. L'écart entre les deux se découvre en construisant, ce qui signifie qu'une partie du travail est, par définition, inconnue au moment d'estimer. C'est ce que décrit le cône d'incertitude : au stade du concept, une estimation défendable peut se tromper d'un facteur quatre dans un sens ou dans l'autre, l'écart se resserrant à mesure que le problème est compris et ne disparaissant qu'à la livraison.

La méconnaissance de la solution. Personne ne sait à quel point l'intégration avec le système legacy est laide avant de l'avoir ouverte. Les estimations portant sur des parties peu familières d'un système sont systématiquement moins bonnes que celles des parties connues, et l'erreur est asymétrique : les surprises allongent les choses, elles ne les raccourcissent presque jamais.

Les biais humains. On imagine le scénario où rien ne se passe mal, et on s'ancre sur le premier chiffre prononcé dans la salle. La tendance à estimer comme si le plan allait tenir est bien documentée, et le remède n'est pas d'exiger de meilleures suppositions, mais de s'appuyer sur l'historique observé de travaux comparables.

Il existe une quatrième source, organisationnelle : une estimation donnée sous pression à une partie prenante qui voulait un chiffre plus petit est le résultat d'une négociation, pas une prévision. Tout processus qui sanctionne les dépassements produira de la marge cachée, et tout processus qui récompense l'optimisme produira des sous-estimations.

Dimensionnement relatif et story points

L'estimation relative contourne la question la plus difficile. Les humains jugent mal une durée absolue et sont nettement meilleurs pour comparer : demandez à une équipe si tel élément est plus gros que tel autre, et elle converge vite.

Un story point est une unité de taille relative qui combine volume, complexité et incertitude. Il n'a aucune valeur temporelle. L'échelle est généralement une suite de Fibonacci modifiée — 1, 2, 3, 5, 8, 13, 20 — parce que l'écart croissant entre les valeurs traduit le fait que la précision diminue quand la taille augmente : distinguer un 8 d'un 13 est possible, distinguer un 21 d'un 23 ne l'est pas. Certaines équipes utilisent des tailles de t-shirt pour la même raison.

Le dimensionnement relatif ne fonctionne qu'avec des stories de référence : deux ou trois éléments terminés dont toute l'équipe se souvient, associés à des valeurs précises. « Ajouter un champ obligatoire avec validation au formulaire existant » vaut 2 ; « l'import CSV avec rapport d'erreurs » valait 5. Les nouveaux éléments se placent par comparaison. Sans références, la valeur des points dérive au fil des mois et tout l'historique perd sa valeur.

Le planning poker en est le mécanisme habituel. Chaque développeur tient une carte, tout le monde la révèle en même temps pour que personne ne s'ancre sur la voix la plus expérimentée, et ceux qui se situent aux extrêmes expliquent leur raisonnement avant un second tour. L'estimation est un sous-produit ; c'est la conversation qui compte, car un grand écart signifie presque toujours que deux personnes imaginent un périmètre différent. Pour les gros backlogs, l'estimation par affinité — trier en silence les cartes au mur par groupes de taille, puis attribuer une valeur à chaque groupe — permet de dimensionner cinquante éléments en une heure avec une précision suffisante.

Les éléments estimés à 13 ou plus doivent en général être découpés avant d'entrer dans un sprint, à l'aide des techniques de découpage présentées dans le guide du product owner.

La vélocité, bien utilisée

La vélocité est le nombre de points que l'équipe termine — au sens de la definition of done — pendant un sprint. Sa seule utilité légitime est d'aider cette même équipe à prévoir son propre avenir.

Utilisez une fourchette, pas une moyenne. Une équipe dont les six derniers sprints ont livré 26, 31, 18, 29, 33 et 24 points a une moyenne de 26,8, mais planifier sur 26,8 donne à peu près une chance sur deux de l'atteindre. Planifier le sprint sur le bas de la fourchette et prévoir la release avec toute la dispersion est bien plus parlant. Ne reportez jamais une vélocité après un changement d'équipe, ne la comparez jamais entre équipes et ne la publiez jamais comme indicateur de productivité : les points sont une unité interne, et dès qu'on les récompense, ils gonflent.

La vélocité se dégrade aussi en silence quand la definition of done est lâche, car du travail inachevé s'infiltre dans le décompte. Si la vélocité est stable mais que rien n'arrive en production, le chiffre mesure de l'activité.

Prévoir à partir du flux

Beaucoup d'équipes obtiennent de meilleures prévisions en ignorant complètement la taille et en comptant les éléments.

Le débit (throughput) est le nombre d'éléments terminés par unité de temps. Le cycle time est le temps écoulé entre le début et la fin d'un élément. Les deux sont mesurés, pas estimés, et tout outil qui enregistre les changements d'état les fournit gratuitement.

L'idée qui sous-tend la prévision par le flux est la suivante : dès qu'une équipe découpe de façon régulière, la taille des éléments est assez homogène pour que les compter soit à peu près aussi prédictif qu'additionner des points — et cela ne coûte rien. Si une équipe termine entre quatre et neuf éléments par semaine et qu'il en reste quatre-vingts, la release tombera quelque part entre neuf et vingt semaines, et vous pouvez l'annoncer dès le premier jour.

La simulation de Monte Carlo transforme cela en distribution. Prenez les échantillons historiques de débit hebdomadaire, effectuez-y des tirages aléatoires répétés pour simuler l'achèvement des éléments restants, lancez dix mille essais et lisez les percentiles.

Éléments restants :   80
Échantillons de débit hebdomadaire (12 dernières semaines) :
  4, 7, 5, 9, 6, 3, 8, 6, 5, 7, 4, 6

10 000 simulations — semaines pour terminer 80 éléments :
  50e percentile (P50)    13 semaines
  70e percentile (P70)    15 semaines
  85e percentile (P85)    17 semaines
  95e percentile (P95)    20 semaines

Message aux parties prenantes :
  « 13 semaines, c'est pile ou face. Nous sommes sûrs à 85 % de
    terminer en 17 semaines au plus. S'engager sur 20 semaines
    est sans risque. »

C'est une conversation bien plus utile que « la release est prévue au T3 », parce qu'elle explicite le niveau de confiance et peut être recalculée chaque semaine à mesure que les données réelles arrivent. Ajoutez un facteur de croissance du périmètre si le backlog a historiquement tendance à grossir pendant la livraison — un ajustement courant et souvent oublié.

L'argument du « no estimates »

Tout un courant de pratiques soutient que, pour beaucoup d'équipes, l'estimation est un pur coût. L'argument est plus solide que ne l'admettent ses détracteurs : si les éléments sont systématiquement découpés petits, la prévision par le débit donne la date sans aucune estimation, et les heures passées en séances de dimensionnement n'apportent rien. Les estimations ont aussi tendance à devenir des engagements, quel que soit le soin mis à les présenter, ce qui les fausse.

Les contre-arguments sont tout aussi réels. Les discussions d'estimation font émerger des malentendus qui, sinon, seraient découverts en plein sprint — la valeur est dans l'échange, pas dans le chiffre. Certaines décisions exigent vraiment un coût avant le début des travaux, par exemple savoir si une fonctionnalité mérite seulement d'être développée, ou laquelle de deux offres contractuelles accepter. Et les organisations qui financent le travail sur une base annuelle ont besoin d'une base de financement.

Une position raisonnable : estimez au niveau où le chiffre change une décision, et arrêtez-vous là. Une taille approximative pour une décision d'investissement trimestrielle vaut la peine d'être produite ; réestimer chaque élément à chaque séance d'affinage, en général, non.

Planification de release et capacité

La planification de release transforme les prévisions en attente partagée. Les données d'entrée sont le backlog ordonné, une fourchette de prévision, les dates fixes connues et la capacité réelle de l'équipe — pas son effectif. La capacité est rognée par les congés, les astreintes de support, les réunions, l'intégration des nouveaux arrivants et la part du sprint réservée aux anomalies : une équipe de six personnes dispose rarement de six personnes à temps plein sur les fonctionnalités.

Maintenez une distinction nette entre capacité et engagement. La révision 2020 du framework a délibérément cessé de présenter le sprint backlog comme un engagement sur un ensemble d'éléments et a fait de l'objectif de sprint l'engagement, précisément parce que la prévision transformée en promesse était devenue le mésusage dominant. Une équipe prévoit ce qu'elle pense terminer ; elle s'engage sur l'objectif.

Pour une release, présentez une fourchette avec des niveaux de confiance, explicitez les hypothèses et refaites la prévision à chaque sprint. Quand plusieurs équipes partagent une release, le coût de coordination change sensiblement la donne — voir l'agilité à l'échelle. Quand le risque de retard est significatif, traitez-le explicitement par la gestion des risques plutôt qu'en gonflant les estimations en douce.

Points clés à retenir

• Les estimations sont des prévisions faites au moment où l'on en sait le moins ; le cône d'incertitude implique qu'un chiffre unique donné tôt est trompeur et qu'une fourchette est honnête.
• Le dimensionnement relatif fonctionne parce qu'on compare mieux qu'on ne mesure dans l'absolu, et il ne tient que si l'équipe conserve des stories de référence.
• Le planning poker existe pour la conversation ; un grand écart entre les cartes signifie que le périmètre est compris différemment, et c'est précisément ce qu'il faut découvrir.
• La vélocité est une donnée de prévision interne à chaque équipe, exprimée en fourchette — la comparer entre équipes ou la présenter comme de la productivité la détruit.
• Compter le débit et lancer une simulation de Monte Carlo donne une date probabiliste avec des niveaux de confiance pour un coût récurrent quasi nul.
• Estimez là où le chiffre change une décision ; engagez-vous sur l'objectif de sprint plutôt que sur une liste d'éléments, et refaites la prévision à mesure que les données réelles arrivent.