Une des arlésiennes des équipes agiles que j’accompagne concerne les estimations de produit en Agile.
Vous savez les fameux « Story Points » ? Ces estimations relatives et globales d’User Stories (ou de Features) si chères aux coachs agiles.

Souvent aux cœurs des préoccupations, ce sujet est jugé comme délicat voire déconnecté de la  réalité pour la plupart des équipes car il nécessite un véritable lâcher prise pour en comprendre tous les bénéfices.

Par cette approche, il s’agit ni plus ni moins d’abandonner l’une des métriques les plus employées par les méthodes de gestion de projet traditionnel : le « Jour / Homme ».
Pour celles et ceux qui ne connaissent pas cette pratique traditionnelle, il s’agit d’évaluer une charge de travail par le nombre de jours nécessaires pour réaliser une tâche ou un ensemble de tâches donné, bien avant le lancement de l’exécution du produit.

 

Pourquoi a-t-on besoin d’estimation ?

Lorsque nous souhaitons réaliser quelque chose nécessitant un investissement financier, nous nous posons régulièrement la question : « Combien est-ce que cela va me coûter ? ».

C’est un besoin naturel et nécessaire avant d’engager un certain budget.

Pour l’exemple :
Quand vous faîtes appel à un artisan cuisiniste, c’est la même chose, vous avez un projet d’installation et vous souhaitez en connaître le coût.

Le Dr. Martin Barnes en 1969 dans une approche Waterfall (en cascade) considère 3 variables interdépendantes, représenté par un « triangle de fer » :

• le périmètre (ce que je veux faire),
• les ressources (comme le coût de main-d’œuvre)
• le temps (les délais).

La compréhension de ce triangle nous permet de déduire la formule suivante :
Temps de réalisation estimé * Coût journalier = Budget nécessaire

Notre ami cuisiniste effectue donc son calcul sur cette base.
Mais, il ne s’arrête pas là. Malin, il sait par expérience qu’il peut y avoir des imprévus, éventuellement chronophage et coûteux pour sa société. En bon gestionnaire et pour finaliser son estimation, il va donc rajouter une marge de temps pouvant varier de 10 à 25%, parfois davantage, faisant bondir le devis qu’il va transmettre à son client.

Mais que se passe-t-il si notre « estimateur » n’est pas celui qui fait ?
Autrement dit, que se passe-t-il si notre artisan doit faire appel à d’autres corps de métiers, complémentaires à son savoir-faire ?
Comment va-t-il pouvoir s’engager sans risque de dépassement de budget et de délais ?
Doit-il prévoir une rallonge budgétaire à chaque risque identifié et à chaque aléa ?

Bref, ce n’est pas simple.

 

A la base de toute planification projet, il y a les estimations.

Estimer les charges et les durées d’un projet informatique complexe à l’aide des méthodologies traditionnelles implique souvent une part importante d’approximations.

Dès lors toutes les techniques magiques, comme la « boule de cristal », le « doigt mouillé », le « à la louche » ou toute autre moyen ésotérique, sont mis à contribution pour évaluer le travail à accomplir, avec plus ou moins de réussite.

Ces prédictions reposent essentiellement sur l’expérience d’un chef de projet à qui l’on confie généralement cette tâche délicate et structurante, pour l’ensemble de la vie du projet.

Néanmoins, malgré tous les efforts et les qualités de la personne qui estime, une grande partie de ses conclusions sont, ou s’avéreront, inexactes :

• Soit pour terminer dans les temps, le logiciel est amputé de certaines caractéristiques (réduction de périmètre)
• Soit la qualité de la livraison est inférieure à un certain seuil attendu, générant des coûts de maintenance très élevés et de graves problèmes une fois en production.
  (dépassement budgétaire)
• Soit la réalisation d’une fonctionnalité donnée prend plus de temps qu’estimé initialement (dépassement de délais ou de charge)
• Soit les 3 à la fois, le projet est jugé « chaotique »: ni le périmètre, ni le budget et ni les délais ne sont respectés.

La loi de Hofstadter est d’ailleurs là pour nous rappeller que : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter… ».

 

Alors, que faire ?

Existe-t-il une alternative aux estimations dites « prédictives » où tout notre plan préalablement défini peut plonger n’importe quelle entreprise ou équipe de réalisation dans le désarroi le plus profond ?

Et bien, au risque de vous décevoir, il n’y a pas de solution magique quand il s’agit de réaliser une œuvre (logicielle ou pas), surtout dans un contexte complexe.

« Un jour j’irai vivre en Théorie, car en Théorie tout se passe bien. » – Inconnu

En effet, l’exécution dans la « vraie vie » n’est que rarement dénué d’aléas, d’obstacles et d’autres merveilles imprévues.

L’approche agile est une approche empirique, basée sur l’expérience. Certains agilistes ont trouvé une solution pour estimer mieux que dans la méthode traditionnelle. Étonnamment, elle parait dépourvue de bon sens car elle n’est pas naturelle. Pourtant, celle-ci présente bien des avantages.

C’est tout l’objet de cet article dédié à l’estimation d’un produit en approche agile.

 

Qu’est-ce que l’estimation relative ?

Pour piloter un projet ou la réalisation d’un produit selon une approche agile, la première chose est d’inverser le triangle de fer.

Là où le Dr. Martin Barnes, dans une approche Waterfall pour le développement logiciel, considère que le périmètre (le scope en anglais) est fixe contrairement aux ressources (soit les moyens financiers et l’équipe) et au délais  qui peuvent être variables, les agilistes prennent le problème à l’envers : ce sont les ressources et les délais qui sont fixées à l’avance et le périmètre devient lui LA variable d’ajustement.

Et comme, pour un projet traditionnel, nous allons avoir besoin des données de notre triangle de fer pour lancer, ou pas, la réalisation de notre produit. A la différence près, que les estimations liées aux périmètres seront effectuées en RELATIF et au GLOBAL.
– EN RELATIF : c’est à dire en comparant les fonctionnalités entre elles : les petites, les moyennes et les grosses fonctionnalités, en prenant le présupposé qu’un point engage plusieurs acteurs pour la réalisation.
– AU GLOBAL : c’est à dire, en prenant en compte la quantité de travail, la complexité, les risques, les inconnues, voire d’autres paramètres non-listé ici.

Il est important de comprendre que les estimations ne sont pas un engagement « sur le sang » ou même une promesse de livraison. Et, pourtant, elles restent nécessaires au pilotage d’un projet, même dans une approche agile.

Vous trouvez cela étrange ? C’est normal, lisez la suite ! 😉

 

Comment estimer en points un périmètre produit ?

Dans les méthodes traditionnelles de pilotage projet, il est courant de donner des estimations en jours-homme.

Par exemple : si j’ai besoin d’un développeur pendant 10 jours pour réaliser telle fonctionnalité et qu’il me coûte 500 euros/ jours alors mon développement me reviendra à : 10 x 500 = 5000 € au total.

Dans les estimations de produits agiles, nous employons d’autres unités de mesure pour estimer le coût et les délais :

• soit en « story points » en suivant la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21…),
• soit en taille de T-shirt (XS, S, M, L, XL, XXL).

💡 Astuce de coach : Les tailles de T-Shirt peuvent aussi être transposées en points pour leur comptage, comme ceci :

 

Planning Poker – les règles du jeu

Dans une équipe agile, nous raisonnons en relatif, en global et collégialement selon la recette suivante de « Planning Poker » :

Initialisation :
L’équipe s’accorde sur une User Story (US) évaluée comme « moyenne » et lui attribue un nombre de points : 5 points, par exemple.
Cette US constitue LA référence qui servira ensuite à estimer toutes les autres US de notre backlog.

Pour le reste des User Stories du backlog :

1/ Description :
Le Product Owner décrit rapidement l’User Story à estimer. L’équipe pose des questions pour la clarifier et pour s’assurer que chaque membre de l’équipe a bien compris celle-ci.

2/ 1er tour d’estimation :
Chaque membre de l’équipe (excepté le Product Owner et le Scrum Master) choisit une carte (1, 2, 3, 5, 8, 13, 21…) en fonction de sa compréhension : soit cette US est plus petite, égale ou plus grande que l’US de référence. Puis, la carte est posée sur la table, face cachée de tous.
Pendant les discussions, il ne faut pas mentionner quelle est la valeur de points choisie.

3/ Découverte :
Dès que tout le monde a posé sa carte, chaque membre révèle simultanément la sienne, rendant visible son estimation (1, 2, 3, 5, 8, 13, 21…).
💡 Astuce de l’Oeil de Coach : La valeur en point d’une carte est globale, c’est-à-dire qu’elle englobe la quantité de travail à fournir (dév. + tests), la complexité, le risque et les inconnues.

4/ Discussion et consensus :
Les personnes ayant attribué les valeurs de points les plus faibles et les plus fortes expliquent leurs choix, la discussion continue jusqu’à l’obtention d’un consensus.

💡 Astuce de l’Oeil de Coach :
– Si vous n’avez pas de carte de Planning Poker, vous pouvez en acheter ici ou bien les fabriquer vous-même avec des post-its.
– Si vous vous rendez compte que certaines User Stories sont trop grosses (>13 points), je vous recommande de les découper en 2 voire 3 morceaux.

 

Quels sont les avantages de l’estimation globale et relative ?

AVANTAGE #1 : LA RAPIDITÉ

La force de l’estimation relative réside dans le fait que celle-ci est facile et rapide à mener.
Etant donné que par définition toute estimation est fausse, alors autant ne pas gaspiller notre temps précieux à sortir un chiffre extrêmement précis sachant que celui-ci sera probablement erroné !
De plus, pour évaluer une User Stories (ou une Features), nous ne sommes plus obligés d’additionner les estimations jour / homme de chacun des intervenants : développeurs, testeurs, architectes, graphistes, intégrateurs, etc. L’approche est globale et relative. N’oubliez pas cela, c’est la clé !

💡 Astuce de l’Oeil de Coach :  Si votre backlog est conséquent, soit des dizaines et des dizaines de fonctionnalités : je vous recommande l’Extreme Quotation.

 

AVANTAGE #2 : LA PRIORISATION

Grâce à l’avantage précédent, la rapidité, on va très vite pouvoir identifier et réaliser ce qui a le meilleur retour sur investissement (ROI), soit le plus de valeur et le moins de complexité.
Cet indicateur est crucial pour les acteurs fonctionnels afin d’adopter la meilleure tactique d’exécution de notre produit.

 

AVANTAGE #3 : LA FIABILITÉ

En utilisant l’estimation relative, nous pouvons nous rapprocher rapidement d’une estimation dont la marge d’erreur sera plus faible par rapport à la méthode traditionnelle en jours / homme, juste après quelques itérations effectuées.
Dans les faits, il s’agit de comptabiliser le nombre de points (« Story points ») à réaliser et de voir ce que l’équipe est capable de fournir en une itération, puis deux, puis trois, etc. On en déduit une vitesse moyenne et l’on peut prédire avec plus de précision quand aura lieu la fin de la livraison.

Par exemple : j’ai 1000 points de fonctionnalités à réaliser et je me suis rendu compte que l’équipe était capable de produire 100 points en moyenne à chaque itération. Je peux donc en déduire que tout sera réalisé au bout de 10 itérations (100 pts x 10 itérations = 1000 points de backlog).

 

AVANTAGE #4 : LA SOLIDARITÉ

Que se passe-t-il quand le chef de projet avait estimé des coûts et des délais intenables, poussant l’équipe à l’échec ?
La cocotte minute enclenchée. La pression monte inéluctablement. Une fois le stress monté à son paroxysme, c’est la foire d’empoigne ! Les managers et l’équipe recherchent des raisons pour se justifier et des prétendus responsables à accabler. L’équipe entre dans un climat délétère profond, pouvant durer des mois.
L’alternative est encore une fois l’estimation relative car celle-ci est globale et partagée. C’est à dire qu’elle prend en compte une évaluation plus large et elle engage le collectif car c’est l’équipe qui assure et assume l’estimation. Les points permettent, eux, de suivre l’activité dans le temps et récompenser le travail collectif, tout en favorisant la solidarité et l’entraide.

 

Comment commencer l’estimation en points quand on ne connait pas la vélocité de l’équipe ?

Pour se mettre le pied à l’étrier, en tant que coach agile, je recommande de choisir une User Story qui prends environ 5 jours / hommes : réalisation, test et livraison comprise.
Cette User Story portera la valeur 5. Elle devient notre US de référence.

Ensuite, vous suivez le mode opératoire présenté ci-dessus, en estimant en relatif et en global par rapport à cette US de 5 points. Simple, non ?

💡 Astuce de l’Oeil de Coach :  Une fois l’US à 5 points identifiée, oubliez les jours / homme pour la suite de l’estimation.

 

Comment piloter mon projet agile avec tous ces points ?

Une fois que votre périmètre projet ou d’itération a été évalué, grâce aux points, vous allez pouvoir le suivre facilement et régulièrement à l’aide de graphique explicite, tout dépendra de l’échelle que vous souhaitez suivre : soit un avancement par jour, par semaine, par sprint, par version, etc.

Voici quelques exemples de graphique :

– Sprint Burn-Down Chart

Souvent mis en place par les Scrum Masters, le « burn-down » se présente de la manière suivante :

Pratique pour :

• Identifier les retards de réalisation,
• Planifier quotidiennement le travail,
• Calculer la vitesse de l’équipe (= vélocité),
• Planifier la livraison du sprint (= 100% des éléments planifiés).

💡 Astuce de l’Oeil de Coach :  passer l’unité de « jours » à « sprints » pour pouvoir prédire la livraison complète de votre produit.
Important : gardez en tête que plus les échéances sont lointaines, plus elles sont incertaines.

– Product Burn-Down Chart

Adoré par les Product Owners et les Product Managers, le « burn-down » se présente de la manière suivante :

Pratique pour :

• Identifier les tendances de réalisation,
• Communiquer l’avancée du projet,
• Suivre les évolutions de périmètre,
• Contrôler le budget et les délais.

 

La conclusion de l’Oeil de Coach 🧐

Comme nous venons de le voir, derrière ses apparences trompeuses, l’estimation relative et globale est assez facile à prendre en main, à condition d’expérimenter.

Contrairement à l’estimation en jours/homme, cette démarche empirique permet de mieux mesurer l’avancement d’un produit, de visualiser la qualité de travail à faire et de suivre avec des graphiques nous permettant de nous projeter sur la durée, et d’agir au plus vite sur le périmètre, les coûts et les délais si cela est nécessaire.

Plus le temps passe et plus nous maîtrisons la capacité à faire de l’équipe et sa prédictibilité dans son environnement agile rendant le pilotage du produit plus sûr et précis, là où les jours / hommes restent figés et ne favorise pas l’amélioration continue.

 

Le Saviez-vous ?

Certains agilistes ont décidé d’aller encore plus loin, guidé par la maîtrise de cette pratique :

Ils se sont rendus compte que la taille des User Stories se compensait entre elles. Ils en ont donc déduit qu’il serait plus simple de compter le nombre de tickets livrés dans un temps donné, puis de baser les prédictions sur cette vélocité.
Plus besoin, par conséquent, de passer du temps à estimer délivrant ainsi plus de temps pour se concentrer sur la création de valeur. Le #NoEstimates est né !
Révolutionnaire, vous ne trouvez pas ? 😉

 

Merci à Amira AMRI et Geoffrey GUILLOCHIN pour leur feedbacks.

Avez-vous aimé cet article ? Partagez-le !
Et, pensez à vous abonner à la newsletter de l’Oeil de Coach. 😉

……… ✂……………………………… ✂………………………………… ✂………

Envie d’aller plus loin ?

• [WEB] Le planning poker  : fonctionnement
• [LIVRE] Les pratiques de l’équipe agile : Définissez votre propre méthode
• [OEIL] Comment rédiger vos User Stories comme Hulk ?
• [OEIL] Comment s’en sortir pour écrire vos User Stories ?
• [OEIL] Les bases de l’agilité en 15 mn chrono !
• [WEB] How to Use Burndown Charts for Transparent and Predictable Development
• [WEB] Transparent Project Management with Burn Up Charts
• [WEB] Pourquoi les prédictions sont-elles souvent fausses? Quelles leçons en tirer ?
• [WEB] Pourquoi les estimations agiles échouent-elles ? (les prérequis) de Jean-Pierre LAMBERT

……… ✂……………………………… ✂………………………………… ✂………

En quoi puis-je vous aider ?

Je suis Martial SEGURA, Coach agile | Expert organisationnel chez Oeil de Coach.

« Mon intention est d’aider les personnes, les équipes et les organisations à atteindre leurs objectifs beaucoup plus vite qu’ils ne le feraient sans ma contribution. »

Je développe le potentiel et les savoir-faire des équipes et des personnes. J’accompagne la transformation agile des organisations, en m’appuyant sur la culture, les valeurs et les pratiques agiles.

Contactez-moi pour en parler :

🚀 Linkedin : https://www.linkedin.com/in/martialsegura
🌐 Blog : www.oeildecoach.com