eXtreme Quotation : estimer la complexité d’un projet en moins de 2 heures

L’estimation du temps de réalisation d’un projet, et de ses différentes tâches, est un des éléments les plus importants dans la bonne conduite de projet.

Dans le développement, bien souvent, les travaux à réaliser sont nouveaux ou contiennent des spécificités qui rendent difficile l’estimation. Combien sont les projets qui dérivent dû à de mauvaises estimations, elles-mêmes dû à une mauvaise compréhension ou une mauvaise expression du besoin. On le voit, de multiples causes sont à l’origine des erreurs d’estimations.

Dans le monde itératif de l’agilité, le planning poker, que l’on effectue pour estimer en points d’effort a pour mérite de partir du postulat suivant : puisque l’estimation en jours ou en heures est peu fiable, prenons une échelle de notation approximative sans unité et exponentielle.

Ainsi, on utilise souvent en agilité la suite de Fibonacci pour estimer la complexité d’une story (ou histoire utilisateur, c’est à dire un incrément fonctionnel d’un projet ou d’un produit). Cette suite (0, 1, 2, 3, 5, 8, 13, 21, 34, etc.) permet d’être précis sur des faibles estimations et d’être plus approximatif sur de grosses estimations. Ainsi, une estimation entre 1 et 2 points d’effort représente un écart du simple au double, tandis qu’une estimation entre 11 et 12 points d’effort a moins d’impact, on privilégie alors la valeur de la suite de Fibonacci supérieur (ou la plus proche selon les pratiques) par sécurité.

Le démarrage d’un projet en méthode agile

La pratique du planning poker (poker décisionnel en français) a néanmoins pour défaut de prendre du temps pour estimer chacun des stories d’un projet. En effet, dans son déroulement, pour chaque story, l’équipe projet se prononce sur son estimation par vote (chaque vote pour un nombre de point d’efforts), puis débat pour se mettre d’accord sur la valeur.

Cette forme d’estimation fonctionne lorsque l’on a besoin d’aller dans le détail et éventuellement de combiner l’estimation avec une phase de compréhension des spécifications de la story (le fameux backlog refinement, ou séance de raffinage en français).

Lorsqu’un projet démarre, on cherche bien souvent à construire une vision d’ensemble du projet, et pour son bon pilotage, à déjà avoir une idée de son point d’atterrissage dans le temps (au-delà du planning officiel annoncé qui lui est un objectif mais pas forcément une réalité).

Il est bien sûr possible d’utiliser le fichier de cadrage, s’il existe, qui se base sur le nombre de jours vendus pour un projet au forfait par exemple. Mais encore une fois, il s’agit ici finalement d’un objectif de rentabilité – est-ce que cette estimation est réaliste maintenant sur les spécifications sont construire dans le détail ?

C’est ici que l’eXtreme Quotation peut aider à se projeter dans le projet.

L’eXtreme Quotation est une pratique issue de l’eXtreme Pragramming, et est une forme de chiffrage comme peut l’être le planning poker.

Cette pratique a pour objectif de donner une estimation d’un grand nombre de stories d’un projet, ou d’une release selon la taille du projet, en un temps très court (1 à 2h maximum). On parle ici de l’estimation d’une centaine de stories environ.

Quelle est la différence entre l’eXtreme Quotation et le planning poker ?

Là où le planning poker propose d’échanger finement sur chacune des stories en débâtant, l’eXtreme Quotation propose de balayer plus rapidement les stories en simultanées (l’ensemble de l’équipe intervient) et de les comparer les unes par rapport aux autres.

Dans le planning poker, les stories sont évalués plus précisément, il en ressort des stories souvent plus claires et des loups sont très souvent relevés et traités en séance. Mais une session de poker planning demande plus de temps, et en début de projet pour construire une vision d’ensemble de ce dernier, nécessiterai un temps incroyablement conséquent. J’ai déjà assisté à des planning poker traitant 5 stories en l’espace d’une heure. C’est le temps qu’il faut, mais pas en début de projet !

Quelles sont les étapes d’un atelier en eXtreme Quotation ?

Il s’agit d’un atelier qui est effectué exclusivement en présentiel, car l’équipe va manipuler… du papier !

Étape 1 : Préparation

Pour mener cet atelier, le Product Owner doit imprimer chacune des users stories dans un format facilement manipulable. Les stories peuvent également être écrit sur post-it (un peu plus long, je vous l’accorde), ce qui compte c’est la mise en évidence du titre et une description sommaire. Évitez donc les renvois vers la page 689, chapitre 2, alinéa 4 des spécifications fonctionnelles.

Des outils comme IceScrum ou Jira, que nous utilisons chez Adimeo, permettent d’exporter un backlog complet ou d’une release dans un format imprimable (PDF ou via transformation sur Excel).

L’atelier se déroule dans une salle comportant une grande surface plane (table ou mur) sur laquelle seront disposés une échelle de point d’effort non numérique. Chez Adimeo, nous plaçons généralement 3 post-it pour représenter l’échelle : $, $$ et $$$ pour indiquer dans quelle direction placer les stories avec le moins de points d’effort et celles avec le plus de points d’effort.

Étape 2 : Découverte avant l’atelier par l’équipe

En amont de l’atelier, (la veille par exemple), l’équipe est invitée à prendre connaissance de l’ensemble des stories.

Cette session de lecture, j’en conviens peu attirante, peut-être dynamisé avec une réunion d’introduction au projet où son contexte est présenté, ainsi que le projet dans son ensemble. C’est important pour que l’équipe raccroche sa lecture à une vision d’ensemble. Pour la concentration de l’équipe, ou du moins pour rendre ce moment plus agréable, pensez au petit déjeuner et quelques collations en cours de journée.

L’objectif pour l’équipe est de lire l’intégralité des stories (titre + description sommaire). Elle peut poser quelques questions au Product Owner pour demander des clarifications sur l’ensemble, mais il ne s’agit pas de rentrer trop dans le détail.

Compter 1 journée pour la lecture d’une centaine de stories, beaucoup de café ou jus de fruit, et quelques pauses.

A l’issue de cette étape, l’équipe n’aura pas retenue l’intégralité du backlog (heureusement), mais de manière combinée, aura une bonne idée du projet et de son contenu.

Étape 3 : Démarrage de l’atelier

Après un shot de vitamine, le coach agile ou le Scrum master ouvre l’atelier et précise les règles du jeu. 5 minutes maximum.

Étape 4 : Estimation de l’équipe

Toute l’équipe en même temps, chacun prend une story, la lit de manière silencieuse et vient la placer sur la surface plane en tenant compte de l’échelle d’estimation.

Les stories viennent se positionner petit à petit les unes à côté des autres (éventuellement les unes au-dessus des autres lorsque le collaborateur est sûr que l’estimation en point d’effort sera la même – mais l’idéal est de se forcer à la positionner avant ou après). Lorsqu’un collaborateur positionne une story, il en profite pour vérifier les stories à gauche et à droite de l’emplacement, pour s’assurer que la story se situe bien entre les deux approximativement en termes de point d’effort. Le placement se fait toujours de manière silencieuse.

Cette estimation dure environ 45 minutes pour une centaine de stories, jusqu’à écoulement du stock.

Des clarifications des stories peuvent être demandés au Product Owner, mais attention à ne pas transformer la discussion en atelier.

💡 Mon conseil
Si la story est trop flou et qu’un débat est lancé, il est recommandé de stopper l’échange et de mettre la story de côté.

Étape 5 : Challenge

Une fois toute les stories positionnées, l’équipe passe à la phase de « challenge ». L’objectif dans cette phase est de passer en revue quelques stories en les comparants avec des stories voisines plus ou moins éloignées. L’idée, ici, est de s’assurer que leur position sur l’échelle de point d’effort est ok.

Par exemple, on prend une story au hasard sur la table et une autre située à 2-3 positions à droite ou à gauche de celle-ci. Une relecture de la story est faite à haute voix et l’équipe est interrogée pour vérifier qu’elle est d’accord avec l’ordre de positionnement des deux stories : Celle de gauche est-elle effectivement plus « simple » et/ou moins « longue » à réaliser que celle de droite ?

Durant cette phase, tout comme la précédente, un ou plusieurs membres de l’équipe peuvent relever des questionnements techniques sur la faisabilité d’une story. Plutôt que de répondre à la problématique en transformant la discussion en débat, il est possible de marquer la story d’un post-it ou d’un symbole pour signifier qu’un atelier technique préalable devra être réalisé pour concevoir la réponse technique. Il sera, alors, possible de revoir l’estimation de la story à ce moment-là.

💡 Bonnes pratiques
Durant cette phase, le Scrum Master peut tenter de redynamiser la session en participant au challenge, principalement en allant chercher des stories au hasard et en interrogeant l’équipe avec des formules du type « vous êtes vraiment sûr ? ». Qu’il connaisse la réponse ou non, l’objectif ici étant de confronter l’équipe dans ces choix.

Le Product Owner, de son côté peut jeter un œil sur certaines stories, les plus chères ou bien celles qui lui semblent élevée « pour ce que c’est » et l’indiquer à l’équipe avec des formules du type « si c’est ce prix-là, je vais revoir ma copie, je trouve ça élevé ! ». Attention, l’objectif, ici encore, est de challenger l’équipe dans ses choix – pas de la forcer à baisser son estimation (ce qui serait contre-productif). Le Scrum Master doit veiller à cela.

Prévoir 15 à 20 minutes pour cette étape.

Étape 6 : Placement des points d’effort

Jusqu’à présent, les stories étaient positionnées les unes par rapport aux autres sur une échelle de point d’effort non numérique. La dernière étape consiste à placer les points d’effort sur cette échelle.

Pour cela, on commence par la story la plus basse de l’échelle et on lui attribue la note de 1 point d’effort (chez Adimeo nous utilisons le dollar [$] comme symbole pour les points d’effort). Les stories suivantes sont également parcourues très rapidement pour évaluer à partir de quelle story la valeur de 2$ doit être attribuée. On note alors les stories précédentes avec la valeur 1$, puis on refait l’exercice pour les stories suivantes, jusqu’à rencontrer la story qui fait passer la valeur à 3$, puis 5$, 8, 13, 21, 34, etc.

Il est possible que la valeur la plus haute de point d’effort ne soit pas une grande valeur ; cela dépend en partie du niveau de granularité de découpage des stories dans le backlog.

Attention de ne pas rentrer dans un débat sur : « Quelle story doit être de la valeur supérieure ? ». Si un débat est lancé, mieux vaut couper court et choisir la valeur supérieure pour avancer et se sécuriser.

Cette étape dure 15 à 20 minutes environ.

💡 Bonne pratique
Pour aider à la décision du passage d’une valeur d’effort à l’autre, il est possible de prendre pour étalon une échelle de durée approximative. Par exemple, l’équipe peut décider que toutes les stories prenant moins de 1 jour de travail sont de 1$, celles situées entre 1 jour et 3 jours de 2$, entre 3 jours et 5 jours, 3$, etc. Attention de ne pas chercher une correspondance entre point d’effort et jour.

Cet étalonnage est conseillé pour une équipe qui débute dans l’utilisation des points d’effort comme unité d’estimation.

Étape 7 : Fin et report dans l’outil

La session se termine sur ces évaluations pour l’équipe. Dans cette dernière étape, le Product Owner est chargé de récupérer l’ensemble des papiers et de reporter les points d’effort de chaque story dans l’outil contenant le backlog (IceScrum, Jira ou autre) ou sur le backlog papier si le projet fonctionne ainsi.

Il dispose désormais d’une vision d’ensemble de l’effort pour le projet ou la release complète. Reste à présent à définir une vélocité, soit en reprenant une couramment constatée pour l’équipe dans un précédent projet, soit à partir du déroulement du 1^er sprint.

À l’issue de cet atelier, le Product Owner est également en mesure de planifier son 1^er sprint.

💡 Mon conseil
N’oubliez pas de planifier les éventuels ateliers techniques demandés durant la session, en amont du sprint où la story sera réalisé (dans le cas contraire, le sprint risque de ne pas être tenue si l’équipe n’est pas au clair sur la réponse technique à apporter).

Ce qu’il faut retenir de cette méthode !

L’eXtreme Quotation est une méthode rapide et efficace pour estimer la complexité des user stories dans les projets agiles. En réduisant le temps d’estimation à seulement 2 heures, cette méthode permet aux équipes de mieux prioriser leurs tâches et de construire une vision d’ensemble du projet, et ceux dès le début. Son caractère simultané et comparatif offre une bonne alternative à la méthode du planning poker, tout en assurant une qualité minimale des estimations. Enfin, en adoptant cette pratique pour vos projets, les équipes peuvent mieux anticiper les défis à venir et planifier leurs itérations avec plus de confiance.

Vous avez aimé cet article, poursuivez votre lecture avec cet article : « Réussir sa transition vers des méthodes agiles »

Crédits photos : fizkes et Adimeo