Les estimations

Les estimations sont … un large sujet de discussion dans toutes les équipes et les organisations.

Aujourd’hui, on constate les éléments suivants :

• Les estimations (au moins dans l’IT) ne reflètent pas la réalité des dates de livraison,
• Estimer, ça prends du temps,
• Certains managers donnent des délais très courts pensant qu’en mettant l’équipe sous pression, elle fera des heures supplémentaires,
• Les ateliers d’estimations qui ont émergés de l’agilité sont détournés.

A ce stade, beaucoup de questions peuvent se poser :

• Avons-nous un retour d’investissement du temps passé à estimer / ré-estimer par rapport à la pertinente et l’utilité ?
• Comment donner un ordre de prix à un client pour effectuer un devis ?
• Devons-nous estimer ou ne pas estimer ?
• Que devons-nous estimer ?
• Comment prioriser deux éléments d’un backlog plus qu’un autre ?
• Comment choisir une solution technique plus qu’une autre ?

En fonction des contextes, les réponses ne sont les mêmes mais l’idée de cet article est de donner des éléments de réponse pour se poser différentes questions.

Première question : Pourquoi avons-nous besoin d’estimer ?

Dans différentes équipes, on trouve différentes raisons poussant à faire des estimations. J’ai listé celle que j’ai rencontré (qui n’est en rien une liste exhaustive ou qui sont des bonnes pratiques !) :

• Avoir un ordre de ‘prix’ d’un ou de l’ensemble des items pour aider le Product Owner à prioriser le backlog produit
• Donner des estimations aux managers
• Créer de la discussion fonctionnelle et technique pour voir si la solution technique est bien conforme aux attentes du produit
• Donner un ordre de prix au client
• Aider l’équipe pour faire un plan de livraison (ou de release ou de saison)
• Faire une roadmap annuelle
• Avoir une vélocité pour déterminer la capacité de l’équipe

A partir du moment où l’on sait pourquoi on estime, on voit rapidement que dans certains cas, il n’est pas forcément très pertinent d’y passer du temps.

Deuxième question : Alors on estime ou on n’estime pas ??

Si l’équipe de réalisation souhaite estimer, qu’elle peut expliquer pourquoi et que cela est réalisé efficacement, alors pourquoi pas. De plus, Scrum (en autre) est empirique et les pratiques étant remises en question régulièrement, si un jour elle juge non pertinente cette pratique, elle n’estimera plus ou autrement.

Si l’équipe de réalisation réalise des estimations sans savoir pourquoi (parce qu’on leur a demander par exemple), c’est problématique. Dans ce cas, avant de prendre une décision, il faut que les demandeurs expliquent leur besoin à l’équipe et qu’il trouve un compromis ensemble. Dans certains cas, les estimations sont conservées (sous une forme optimisée ou pas) et dans d’autres cas, les estimations ne seront plus effectuées. Encore une fois, tout dépend du contexte.

Troisième question : Comment peut-on construire une roadmap de l’année ?

En général, les équipes de réalisation demandent une vision, une vue sur l’année. La réponse est par exemple de faire une roadmap. Problème…quand on fait une roadmap elle est partagée et elle est considérée comme ‘juste’ et comme un engagement. On va donc estimé pour éviter d’entendre qu’on s’est trompé…

Si l’on part du principe qu’une roadmap est un outil pour donner un ordre d’idée du cheminement d’un ou plusieurs produits dans une organisation, à mon sens, une discussion entre toutes les parties (management, équipe, etc) est suffisante. Ceci sera d’autant plus constructif que l’équipe de réalisation pourra indiquer ses doutes et ses risques, et le management pourra réagir.

Quatrième question : Comment honorer des engagements contractuels ?

Dans certains cas, il y a des dates importantes. Des dates déjà annoncées sans qu’elles puissent être décalées (événements sportifs par exemple).

Comment savoir s’il sera possible de livrer toutes les fonctionnalités ?

Estimation ou pas, il faut livrer.

Au lieu d’estimer, il est plus pertinent de réfléchir au produit minimal à fournir pour la livraison et de la meilleure stratégie de développement à mettre en place pour être dans les temps. Le produit n’a pas besoin d’être parfait mais il doit fonctionner. Cette réflexion doit être menée avec le client final. En règle général, on s’aperçoit que le client ne demande pas ce que l’on pense et dans la majeure partie des cas, il est possible de trouver un bon compromis (technique/périmètre fonctionnel) pour respecter la date.

Cinquième question : Comment évaluer un devis ?

Comme pour la question précédente, la création du devis doit se faire avec le client, en l’accompagnant pour définir son produit et évaluer les risques. Dans le cas d’un produit classique, il est possible d’utiliser des ‘abaques’ pour évaluer le montant. Dans le cas d’un produit complexe, avec beaucoup d’incertitudes, j’ai rencontré plusieurs cas de figures :

• On est en confiance avec le client, et il est consentant si les délais sont légèrement plus long et soumis à une phase de ‘dérisquage’, il sera toujours possible de trouver un arrangement : si le produit coûte moins cher, on ajoute quelques fonctionnalités, si le produit coûte plus cher, le client ré-injecte de l’argent, ou un arrangement commercial est proposé pour une future collaboration, ou encore le client prend à sa charge la promotion du produit par exemple.
• Le client souhaite avoir un devis et qu’il ne bouge pas. Dans ce cas, il est tout à fait possible de se faire financer un ‘dérisquage’ sous forme de poc ou de spike sans obligation de résultat (engagement de moyen) pouvant débloquer le projet total.

Sixième question : Comment sélectionner les items à embarquer dans un sprint d’une équipe Scrum ?

Les équipes Scrum utilisent souvent la vélocité pour en déduire sa capacité. D’ailleurs, les nombreux outils intègrent cette fonctionnalité. Cela pousse forcément à tout estimer afin d’avoir une vélocité.

Dans la pratique, chaque sprint est différent (congés, urgences, blocage technique, etc). Même en faisant une moyenne de la vélocité des sprints passés, on peut se poser la question de la pertinence de cette métrique.

Ce que j’observe, c’est que la vélocité n’aide pas vraiment les équipes pour choisir quoi embarquer dans les sprints. La version la plus simple est de simplement demander le degré de confiance à l’équipe.

De là, s’engage des conversations entraînant une stratégie de développement à adopter pour le sprint et naturellement, des items seront mis de coté ou dans le mou du sprint.

Quelle conclusion tirée autour des estimations ?

Par expérience, on cherche à faire des estimations avant de se poser la question : De quoi avons-nous réellement besoin pour le produit et quelle stratégie de développement allons-nous adopter pour se respecter la date souhaitée ?

La première interrogations autour du produit va permettre d’épurer le backlog produit et de développer les bonnes choses dès le début du projet. Concernant la stratégie de développement, elle pose les bases de l’architecture conformément à la date souhaitée.

En ayant cette stratégie (produit et technique), il devient plus naturelle de ne pas estimer les éléments ou d’utiliser les estimations seulement par parcimonie pour aider à prendre une décision pendant le déroulement du projet. En fonction des dates et du budget, l’équipe a le devoir d’indiquer les problèmes que l’on pourrait rencontrer pour les évolutions du future du projet afin que le client en soit conscient et que cela impactera forcément le prix de futures évolutions.

Concernant la construction des sprints, durant la planification, l’équipe de réalisation adoptant une stratégie de développement, va naturellement supprimer ou ajouter des éléments dans le sprint.

Enfin, si l’équipe a l’habitude de créer sa discussion autour d’un planning poker et que cela est efficace, il est tout à fait possible de conserver cette pratique.

En conclusion, il n’existe pas de réponse tranchée sur la question des estimations. Il faut trouver le bon compromis entre le bon sens et le besoin d’estimation ponctuelle en fonction de son contexte.

Crédits : Photo by Sarah Ehlers on Unsplash