Estimation, affinage et mesure

Pratique : estimation, affinage et mesure

1. Estimer : la valeur, la taille, l'incertitude

   Estimer n'est pas prédire une date. C'est permettre à l'équipe de prendre une décision sur la base de ce qu'il lui est réellement possible de faire.

   Trois nombres, trois usages distincts

   • la valeur : ce que l'élément apporte au produit — bénéfice pour l'utilisateur, pas charge de travail. Elle sert à ordonner le Product Backlog ;
   • la taille : l'effort relatif, en points, pas en heures. Les points n'ont pas à être convertis en temps : la conversion n'est pas stable, elle varie selon la personne, le contexte et la fatigue ;
   • la confiance : à quel point l'équipe croit à son estimation.

   Pourquoi des points plutôt que des heures

   Convertir des heures promet une précision que personne n'a. Les heures sont directement corrélées à la vitesse de chacun, à son expérience du sujet, et à ce qu'il a dans la tête ce matin-là. Deux développeurs qui donnent des estimations en heures ne sont pas comparables : elles décrivent deux personnes, pas une tâche.

   Une échelle grossière — 1, 2, 3, 5, 8, 13, 21 — est volontairement imprécise. Elle force la conversation sur ce qui est réellement demandé, et c'est cette conversation qui a de la valeur, pas le nombre obtenu.

   Le piège de la vitesse comparée

   Comparer la vélocité d'une équipe à celle d'une autre n'a aucun sens : elle dépend de la taille de l'équipe, des personnes, de la maturité, du domaine. C'est un outil de prévision pour l'équipe, à elle-même. Le transformer en indicateur de performance individuelle produit l'effet inverse de celui recherché : les équipes gonfleront leurs estimations pour paraître prévisibles, et la fiabilité disparaîtra.

   Ce qu'une estimation n'est pas

   Un engagement. La distinction est juridique autant qu'organisationnelle : une estimation est une prévision fondée sur l'information disponible. Un engagement est une promesse, et le Guide 2020 emploie volontairement le mot commitment pour les artefacts — pas pour les dates.

2. L'affinage : rendre le travail planifiable

   Un élément trop gros ne peut pas être estimé, et ne peut pas être terminé dans un sprint. L'affinage le rend Ready : suffisamment compris, découpé et petit pour entrer dans un sprint.

   Ready et Done : deux états symétriques

   La version 2020 a introduit cette symétrie, qui clarifie beaucoup de discussions floues :

   • Ready : l'élément peut être planifié — assez clair, assez petit, avec les dépendances connues ;
   • Done : l'incrément respecte la Definition of Done.

   Un élément Ready mal découpé conduit à un travail non terminé ; un élément Done qui ne l'est pas conduit à une fausse livraison. La transparence porte sur les deux extrémités, pas seulement sur l'avancement.

   Découper sans perdre le sens

   Le découpage vertical — une tranche de fonctionnalité qui traverse toute la pile — est préférable au découpage horizontal, qui produit des couches technique inertes : la base de données est prête mais l'écran ne fait rien. L'élément découpé verticalement est démontrable, donc testable, donc réellement fini.

   L'affinage est du temps de production

   Le Product Owner et l'équipe affinent pendant l'itération, pas la veille du sprint. Le meilleur test : l'élément ne peut pas être décrit en une phrase par l'utilisateur, il n'est pas prêt. Tout le reste — discussion technique comprise — relève de l'estimation, pas de l'affinage.

3. Mesurer : ce qui sert, ce qui égare

   Une mesure qui ne change aucune décision est une charge. Cette question doit précéder tout choix d'indicateur.

   Le graphique d'avancement : ce qu'il ne dit pas

   Un graphique d'avancement suppose que l'on sait combien de travail reste. Dans une équipe qui apprend, cette quantité change en permanence : un Affinage détaillé, une difficulté découverte, une dependance levee. Le graphique sature alors, ou décroche, sans que rien ne soit réellement faux.

   Il reste utile à condition d'être lu comme une conversation sur la prévision, jamais comme une mesure de performance. Utilisé de la seconde manière, il provoque exactement le comportement qu'il prétend éviter : gonfler les estimations pour que la courbe reste jolie.

   Les indicateurs qui tiennent leurs promesses

   • le temps de cycle : durée entre le moment où un élément entre dans le flux et celui où il est terminé. Il décrit la santé du système de production de valeur, et il ne se dégrade pas quand on améliore les pratiques ;
   • le taux d'achèvement des Definition of Done : il distingue le travail réellement livré du travail déclaré ;
   • la fréquence de livraison : en incréments, pas en tâches. C'est la meilleure mesure de la capacité d'un système à produire de la valeur ;
   • le délai de reprise après incident : souvent absent des tableaux de bord, alors qu'il conditionne directement la confiance du client.

   La règle d'or de la mesure d'équipe

   Un indicateur d'équipe ne doit jamais être utilisé pour comparer deux personnes. Utilisé à l'envers, il dégrade la collaboration, encourage la répartition défensive du travail, et finit par rendre la mesure fausse. Une mesure qui a déformé le comportement qu'elle voulait observer n'est plus utilisable, quelle que soit sa qualité méthodologique.