Une nouvelle équipe, un nouveau produit ou un backlog qui s’est discrètement étoffé pour atteindre deux cents éléments : si vous attribuez un point à chacun d’entre eux au « planning poker », vous vous exposez à des journées entières de réunions. L’estimation par affinité permet d’évaluer ce même backlog en une seule session, souvent en une heure environ. Cela fonctionne parce que cette méthode inverse l’ordre habituel. L’équipe commence par classer l’ensemble des éléments en groupes plus ou moins importants, sans attribuer de chiffres, et n’attribue des étiquettes à ces groupes qu’une fois l’ordre relatif établi. Lorsque les chiffres entrent en jeu, les discussions qu’ils suscitent habituellement sont déjà terminées.

Ce chapitre propose une présentation conceptuelle de cette technique : en quoi elle consiste, comment se déroule une séance, dans quels cas elle fait ses preuves et dans quels cas elle échoue discrètement.

Qu’est-ce que l’estimation d’affinité ?

L’estimation par affinité est une technique d’évaluation relative. Au lieu de demander « combien de points représente cette story ? » élément par élément, vous posez une question plus simple à l’ensemble du backlog : lequel de ces éléments est plus important que l’autre ? L’équipe dispose les éléments sur une ligne, du plus petit au plus grand, en regroupant ceux qui semblent nécessiter un effort similaire, et les tailles ressortent de cette disposition plutôt que d’un vote élément par élément.

Le mécanisme qui rend cette méthode rapide est précisément celui qui la rend efficace : vous triez d’abord, puis vous attribuez les notes à la fin. Les gens sont lents et ont tendance à se disputer lorsqu’il s’agit de porter des jugements absolus (« est-ce un 5 ? ») et rapides et assez fiables lorsqu’il s’agit de jugements comparatifs (« ceci est plus grand que cela »). L’estimation par affinité repose entièrement sur la comparaison, pour laquelle une équipe est douée, et réserve les chiffres pour la toute fin, lorsqu’ils ne sont presque plus qu’une formalité.

Le chapitre « Techniques d’estimation » de ce guide compare les principales approches côte à côte et consacre une brève entrée à l’affinité. Voici la version longue de cette entrée. Ce qui distingue l’affinité des autres méthodes présentées ici, c’est le débit. C’est la technique à laquelle vous recourez lorsque le problème n’est pas de « comprendre cette histoire en profondeur », mais de « classer grossièrement toute une pile d’histoires, dès aujourd’hui ».

Quand l’utiliser, et quand ne pas l’utiliser

Exprimons clairement ce point : l’estimation par affinité sert à évaluer l’étendue et la rapidité, tandis que le planning poker permet d’approfondir le travail à court terme. Ces deux méthodes ne sont pas concurrentes. Elles répondent à des questions différentes.

Optez pour l’estimation par affinité lorsque vous disposez d’un backlog volumineux ou que vous ne le connaissez pas bien et que vous avez besoin rapidement d’une base de référence commune :

  • Une nouvelle équipe qui évalue pour la première fois le volume de son backlog, sans pouvoir s’appuyer sur un historique de vélocité.
  • Un nouveau produit ou une nouvelle épopée qui vient d’être décomposée en dizaines d’histoires.
  • Une session de mise au point où le fait de vérifier chaque élément individuellement vous prendrait des jours dont vous ne disposez pas.

Privilégiez plutôt le « planning poker » lorsque les stories sont peu nombreuses, bien comprises et sur le point d’être validées. L’intérêt du « planning poker » réside dans la discussion que chaque story suscite avant que quiconque ne s’engage dans un sprint. Cette discussion mérite d’être menée pour les dix stories en tête du backlog. Elle ne vaut pas la peine d’être menée, une par une, pour l’ensemble des deux cents.

En réalité, la situation se présente ainsi : l’estimation par affinité est un outil de chiffrage préliminaire, et non un outil permettant de s’engager sur un sprint. Le travail à court terme fait toujours l’objet d’une nouvelle estimation en points avant que l’équipe ne s’y engage. L’estimation par affinité permet de cartographier l’ensemble du backlog. La méthode Poker permet de planifier les prochaines étapes à travers celui-ci.

Affinity small large the whole backlog, one pass Planning poker 5? 3! 3 5 8 a few stories, in depth Breadth first, then depth where you commit.
L’estimation par affinité couvre l’intégralité du backlog en un seul passage. Le « Planning Poker » permet d’approfondir les quelques stories qui seront traitées ensuite.

Comment animer une séance, étape par étape

L’estimation d’affinité s’effectue sur une surface partagée que tout le monde peut voir en même temps, et elle est, de par sa conception, pratiquement silencieuse.

  1. Notez chaque élément sur un post-it. Un élément du backlog par post-it ou par fiche. Ne les triez pas à l’avance.
  2. Définissez un point de référence. Choisissez un objet que l’équipe connaît bien, placez-le au centre de la surface et convenez qu’il servira de point de repère pour le « moyen ». Tous les autres éléments seront positionnés par rapport à celui-ci.
  3. Triez en silence. L’équipe classe les éléments restants de gauche à droite en fonction de l’effort relatif qu’ils requièrent : les plus simples à gauche, les plus complexes à droite. Pas encore de discussion. C’est le silence qui empêche la voix la plus forte de dominer la réunion.
  4. Déplacez une note si vous n’êtes pas d’accord. Si vous pensez qu’un élément n’est pas à sa place, déplacez-le. Aucune autorisation n’est nécessaire, pas de discussion.
  5. Ne discutez que des cas particuliers. Une remarque qui revient sans cesse sur le tapis témoigne d’un désaccord tacite au sein de l’équipe. Ce sont ces cas-là, et uniquement ceux-là, qui méritent que l’on s’y attarde. Tout ce qui a été réglé sans heurts fait déjà l’objet d’un accord.

Cette méthode s’applique aux étapes trois et cinq. Vous ne cherchez pas à discuter de chaque élément. Vous laissez le tri faire ressortir les quelques éléments qui nécessitent réellement une discussion, et vous ne vous occupez pas des autres.

Vous n’avez pas besoin d’un outil d’estimation spécialisé pour cela. Ce dont vous avez besoin, c’est d’une surface que toute l’équipe puisse voir et sur laquelle elle puisse intervenir simultanément : un mur et une pile de post-it dans une pièce, ou tout autre espace de travail partagé sur lequel votre équipe travaille déjà lorsque ses membres sont en télétravail. La contrainte réside dans la simultanéité, et non dans l’outil utilisé.

Regrouper en catégories et convertir en points de story

Une fois que le tri cesse de bouger, vous obtenez une répartition régulière de gauche à droite, mais sans aucun chiffre pour l’instant. C’est à ce moment-là, et uniquement à ce moment-là, que vous tracez les lignes.

Regroupez les montants en quelques catégories et attribuez à chacune une valeur issue de votre échelle habituelle. Certaines équipes utilisent les lettres S, M et L. La plupart se tournent vers la suite de Fibonacci (1, 2, 3, 5, 8, 13), la même que celle qu’elles utiliseraient au poker. Le groupe le plus petit correspond à vos 1 et 2, le suivant à vos 3, et ainsi de suite. Chaque élément d’un groupe hérite du numéro de ce groupe.

Le fait de ne fixer les notes qu’en dernier lieu est l’essence même de la méthode, et non un simple détail de l’ordre de traitement. Au moment où vous attribuez un 5 à un groupe, l’équipe s’est déjà mise d’accord sur le fait que ces éléments vont ensemble et se situent à droite des 3. Il n’y a plus matière à débat, car la question épineuse (« est-ce plus important que cela ? ») a trouvé sa réponse lors du tri. La polémique au cas par cas (« est-ce un 3 ou un 5 ? ») qui accapare les sessions de Planning Poker n’a jamais l’occasion de s’engager.

A backlog sorted into Small, Medium and Large columns on the TeamRetro online whiteboard during an affinity estimation session
Exemple d’estimation d’affinité dans TeamRetro à l’aide du tableau blanc en ligne.

C’est là que l’estimation d’affinité prend toute sa valeur à double titre : elle permet également de repérer très tôt les éléments trop volumineux. Un élément qui se retrouve isolé à l’extrême droite, bien au-delà de tous les autres, est presque toujours une épopée portant l’étiquette « histoire ». L’estimation par affinité le met clairement en évidence lors du raffinement, plusieurs semaines avant qu’il ne vienne perturber une session de planification de sprint sous la forme d’un élément 21 impossible à diviser.

Les limites de l’estimation d’affinité

La rapidité a un prix, et il est important d’en discuter avant de programmer une séance.

Cela masque les désaccords. Une méthode silencieuse assimile le silence à un consentement. Une story qui, en privé, était un mélange de 3 et de 8 peut se stabiliser sur des 5 sans que personne ne s’en aperçoive, et le désaccord n’apparaît qu’au milieu du sprint. Le Planning Poker oblige à mettre ce désaccord sur la table, une story à la fois, ce qui explique précisément pourquoi ce processus est plus lent.

Tout le monde doit se trouver sur la même surface au même moment. Le tri silencieux repose sur le fait que les participants placent et déplacent les éléments simultanément. Si vous le mettez en pratique dans un contexte où l’équipe ne peut pas voir ni toucher la même disposition, le tri se résume alors à celui qui place les éléments en premier, ce qui est précisément l’effet d’ancrage que cette méthode vise à éviter.

C’est approximatif, et cela doit le rester. Le résultat obtenu est une fourchette approximative, et non un chiffre que vous défendez lors de la réunion de planification de sprint. Considérer une catégorie d’affinité comme une estimation ferme, c’est transformer une première estimation rapide et utile en une promesse que personne n’avait l’intention de faire.

C’est précisément pour ces trois raisons que cette technique vient compléter le poker plutôt que de le remplacer : il faut d’abord évaluer l’ensemble du backlog, puis réestimer correctement la partie supérieure de celui-ci avant de s’engager.

Un exemple détaillé

Imaginons qu’une équipe ait 60 stories pour un nouveau module de reporting et qu’elle ne dispose d’aucun historique sur lequel se baser pour estimer l’ampleur du travail.

Ils notent chaque cas sur une fiche et placent au centre un cas familier, « exporter un rapport au format CSV », qui servira de référence. Pendant quinze minutes, l’équipe trie le reste en silence. Une modification de la procédure de connexion se retrouve tout à gauche, un tout nouveau moteur de création de graphiques glisse tout à droite, et la plupart des éléments se regroupent de manière informelle autour de la référence. Quelques fiches sont déplacées deux fois. Celles-ci font l’objet d’une brève discussion avant de trouver leur place.

Ils tracent ensuite quatre lignes de délimitation et attribuent les numéros 2, 3, 5 et 8 à ces groupes. La modification de la procédure de connexion et les éléments qui lui sont associés font partie du groupe 2. Le moteur de création de graphiques se trouve isolé au-delà du groupe 8 ; l’équipe le signale donc : il s’agit en réalité d’une épopée, et elle est scindée avant la planification du module. En moins d’une heure, 60 stories non estimées se voient attribuer une taille commune et justifiable, et l’élément qui aurait pu faire dérailler un sprint est repéré alors qu’il est encore temps de le décomposer.

Comparez cela au poker. Soixante récits de trois minutes chacun, cela représente trois heures de discussion ininterrompue, et l’équipe aurait probablement perdu patience bien avant que le moteur de visualisation ne fasse son apparition.

Et maintenant, quelle direction prendre ?

L’estimation par affinité aboutit à un backlog dimensionné, et non à un plan de sprint. Les stories situées en haut de la liste méritent encore d’être examinées de plus près avant que quiconque ne s’engage à les réaliser, et c’est là le rôle du « planning poker » : des votes à l’abri des regards, une révélation des résultats, et une véritable discussion lorsque les chiffres divergent. Lorsque vous en arrivez à cette étape, le Planning Poker gratuit pour les équipes agiles constitue un moyen simple de mener cette démarche, et le reste du guide d’estimation agile aborde les points d’histoire, la vélocité et les habitudes de raffinement qui donnent tout leur sens à ces chiffres.

Foire aux questions

Qu’est-ce que l’estimation d’affinité dans la méthode agile ?

L’estimation par affinité est une technique de chiffrage relatif rapide. L’équipe commence par classer le backlog en groupes « plus grands » et « plus petits », sans leur attribuer de chiffres, puis attribue des étiquettes à ces groupes (S, M et L, ou une échelle de Fibonacci) uniquement une fois que l’ordre relatif est établi. Comme les chiffres n’interviennent qu’en dernier lieu, l’équipe ne se retrouve jamais bloquée à débattre pour savoir si un élément donné correspond à un 3 ou à un 5. Cette méthode est conçue pour évaluer rapidement un backlog volumineux ou tout nouveau, et non pour s’engager sur le travail d’un seul sprint.

Comment menez-vous une séance d’estimation d’affinité ?

Notez chaque élément du backlog sur un post-it, sur un mur ou sur toute autre surface visible par l’ensemble de l’équipe. Choisissez un élément de référence, placez-le au centre, puis demandez à l’équipe de classer silencieusement les autres éléments de gauche à droite en fonction de l’effort relatif requis, du plus faible au plus important. Toute personne en désaccord avec un classement déplace le post-it. Si un post-it ne cesse de changer de place, c’est le signal qu’il faut s’arrêter et en discuter. Une fois que la disposition ne change plus, tracez quelques lignes de délimitation pour diviser l’ensemble en catégories et nommez-les. Une session de ce type permet d’évaluer la charge de travail de quelques centaines d’éléments en environ une heure.

Dans quels cas vaut-il mieux recourir à l’estimation par affinité plutôt qu’au « planning poker » ?

Utilisez l’estimation par affinité pour une première estimation de l’ampleur d’un backlog important ou nouveau, lorsque vous avez besoin d’une vue d’ensemble, de rapidité et d’une base de référence commune. Utilisez le « planning poker » pour approfondir le travail à court terme auquel une équipe s’apprête à s’engager, lorsque la discussion suscitée par chaque story est l’objectif principal. L’estimation par affinité vous permet d’obtenir une estimation approximative de l’ensemble du backlog en une seule session. Le « planning poker » vous permet d’identifier une poignée d’histoires suffisamment bien cernées pour être intégrées à un sprint. La plupart des équipes utilisent les deux méthodes : l’estimation par affinité pour cartographier le terrain, et le « planning poker » pour planifier les prochaines étapes à franchir.

Comment transformez-vous les groupes d’affinité en points d’histoire ?

Une fois les éléments triés et regroupés, tracez des limites entre les groupes et attribuez à chaque catégorie une valeur issue de votre échelle habituelle, le plus souvent une suite de Fibonacci (1, 2, 3, 5, 8, 13). Le groupe le plus petit correspond à vos « 1 » ou « 2 », le suivant à vos « 3 », et ainsi de suite. Chaque élément d’un groupe hérite du numéro de ce groupe. L’ordre est important : vous ne fixez les numéros qu’une fois le tri relatif établi, ce qui empêche justement que la polémique sur chaque élément ne commence.

Avez-vous besoin d’un outil pour effectuer une estimation d’affinité ?

Pas nécessairement, mais cela peut aider. Un mur ou une pile de post-it peuvent faire l’affaire, si cela ne vous dérange pas de tout réécrire et de réattribuer des étiquettes. L’essentiel est de disposer d’un espace simple où tout le monde peut voir la même disposition et déplacer des éléments dessus en même temps. Que vous utilisiez une pile de post-it ou le tableau blanc en ligne de TeamRetro, les deux solutions fonctionnent.

Quels sont les inconvénients de l’estimation d’affinité ?

Cette méthode masque les désaccords, car une approche silencieuse assimile le silence à un consentement, et une divergence d’opinion peut se glisser dans un « panier » sans que personne ne s’en aperçoive. Elle repose sur le fait que tout le monde travaille sur la même surface en même temps ; or, lorsque ce n’est pas le cas, elle se transforme en « ancrage ». De plus, elle est délibérément approximative, de sorte que le résultat obtenu est une fourchette grossière plutôt qu’une estimation sur laquelle baser un sprint. Ces limites expliquent pourquoi la plupart des équipes l’associent au « planning poker » pour le travail à court terme, plutôt que de l’utiliser pour tout.

Lectures complémentaires

Source : l’article de Mike Cohn sur l’estimation relative, disponible à l’adresse Mountain Goat Software sert de base à l’approche de dimensionnement relatif décrite ici.