Estimer tout un backlog en moins d'une heure

La pratique

En début de release ou de projet, il faut souvent donner un ordre de grandeur à tout un backlog : des dizaines d'éléments, parfois une story map entière. Le planning poker, élément par élément, y laisse une demi-journée et l'attention de l'équipe.

eXtreme Quotation, décrite par OCTO Technology, part d'un constat simple : comparer deux éléments est plus rapide et plus fiable que chiffrer chacun dans l'absolu. Lors de leur premier essai, une équipe a estimé environ 90 stories en une vingtaine de minutes. On retrouve la même idée dans l'estimation par affinité (affinity estimation) ou le Magic Estimation : ranger les éléments les uns par rapport aux autres plutôt que les chiffrer un à un.

Avant la séance

• Deux tables. Au centre, la table d'estimation, sans chaises pour circuler autour. À côté, la table des éléments à estimer, imprimés sur des cartes ou des post-it.
• Des colonnes. La table d'estimation est découpée au ruban adhésif en six ou sept colonnes, chacune coiffée d'une carte de planning poker : la suite de Fibonacci jusqu'à 100, plus une colonne « ? » pour ce qui ne peut pas être estimé.
• Un étalon. Une ou deux stories de référence, choisies à l'avance par l'équipe, sont posées en premier dans leur colonne.
• Les bonnes personnes. Les développeurs et les testeurs estiment. Le Product Owner et les experts métier sont présents pour répondre aux questions, pas pour estimer.

Le déroulé en trois temps

1. Le premier tri. Tout le monde pioche en même temps et place les éléments à l'intuition. N'importe qui peut déplacer n'importe quelle carte. En cas de doute, on choisit la colonne au-dessus. Une dizaine de minutes suffit.
2. On secoue le résultat. Quand plus rien ne bouge, l'animateur pose une question, une seule, et attend que les cartes se stabilisent avant la suivante : « Tout le monde a-t-il regardé chaque élément ? », « Un élément est-il à deux colonnes de sa place ? », « Pourrait-on démarrer la prochaine itération avec ces estimations ? »
3. On fige. Quand les questions ne font plus bouger aucune carte, on note sur chacune la valeur de sa colonne.

Ce que l'on estime

Une grandeur relative, propre à l'équipe, et non des jours. OCTO propose de raisonner sur la complexité à tester entièrement la fonctionnalité : une fois livrée, combien de tests faudrait-il pour s'assurer qu'elle fonctionne, et de quelle difficulté ?

Quand l'utiliser

La méthode échange de la précision contre de la vitesse. C'est un bon marché quand le volume est grand et que l'on cherche un ordre de grandeur, un mauvais quand chaque élément mérite une vraie conversation.

Les éléments rangés à 40, à 100 ou dans la colonne « ? » sont un résultat en soi : ce sont eux qu'il faut découper ou clarifier avant de les planifier.

Retour d'expérience terrain

Le contexte

L'atelier a eu lieu pendant la préparation d'un PI Planning, sur un sujet priorisé tardivement. Les conditions étaient presque toutes celles que je déconseille plus haut : des stories inégalement cadrées, une équipe nouvelle, sans référence commune, et une séance montée dans l'urgence. Il fallait pourtant arriver au PI Planning avec un ordre de grandeur sur l'ensemble du sujet.

Ma variante

Je ne commence pas par le tri collectif de la version d'origine. Chacun reçoit quelques stories tirées au hasard et les place en silence ; personne n'attend l'avis du plus expérimenté. Ensuite, chaque coéquipier repasse sur le classement des autres et reclasse selon sa vision. Une carte qui ne bouge plus fait consensus, une carte qui fait des allers-retours mérite une discussion avec tous les acteurs. L'échelle dépend de l'équipe, le plus souvent Fibonacci. Comptez trente minutes à une heure pour plusieurs dizaines d'éléments.

Ce qui a manqué

La préparation, d'abord. Les enjeux de la séance n'avaient pas été partagés assez tôt, et tous les équipiers n'avaient pas compris ce que l'on attendait d'eux : une partie de l'atelier a servi à l'expliquer. Ensuite, tout le monde n'a pas pu être présent : en pleine préparation de PI Planning, plusieurs membres de l'équipe étaient pris sur d'autres ateliers. Les estimations reposaient donc sur une partie de l'équipe seulement.

Ce que l'équipe en a tiré

L'objectif a été atteint malgré tout. Le plus utile n'a pas été le chiffre posé sur chaque carte, mais l'effort fait par l'équipe pour repérer les sujets à redécouper, jusqu'à obtenir un ensemble de taille homogène.

Nous sommes repartis avec deux résultats. Pour le PI Planning, un premier lot de livrables défini. Pour la suite, un référentiel d'estimation riche, des stories de chaque taille sur lesquelles l'équipe peut s'appuyer en Sprint Planning. Pour une équipe qui n'avait aucune référence commune, c'est sans doute le gain le plus durable.

Si c'était à refaire : partager le backlog et l'enjeu quelques jours avant, et réserver le créneau dans l'agenda du PI Planning pour que toute l'équipe soit autour de la table.

Limites à garder en tête

• Une estimation relative n'est pas une durée. Les valeurs n'ont de sens que pour cette équipe et ce backlog ; ne les comparez pas d'une équipe à l'autre.
• La vitesse peut masquer un malentendu. Un élément vite placé n'est pas forcément compris : la phase où l'on secoue le résultat sert à le vérifier.
• Le groupe a ses dynamiques. Les plus assurés déplacent plus de cartes. L'animateur veille à ce que chacun passe autour de la table.
• Estimer ne remplace pas découper. Les gros éléments restent gros : la séance les signale, elle ne les rend pas plus prévisibles.

Pour aller plus loin : la description d'origine par OCTO Technology, « eXtreme Quotation: Agile Planning on steroids » (en anglais).