08 – Estimation de charges et "contrat produit" en mode agile

Utiliser comme unité d’œuvre le principe de la journée "Non Idéale" en mode agile apparaît comme un choix judicieux. Les "Points normalisés" de SAFe viennent conforter ce choix.

En matière d’estimation de charges, de nombreux agilistes choisissent les « Points de complexité relative » associés à la suite de Fibonacci (pour la granularité). Depuis les débuts de l’agilité cela n’a jamais été mon cas. Après avoir testé l’inanité d’usage de ce type d’estimation, puis les « ideal days» de Mike Cohn - j’utilise comme unité d’œuvre le principe de la journée « Non Idéale ». Les « Points normalisés » de SAFe viennent d’ailleurs de conforter ce choix.

L’estimation, un processus réellement itératif

Totalement complémentaires, les trois techniques que sont la priorisation, l’évaluation, puis la planification n’en sont pas moins fondamentalement différentes en termes de maturité et de précision. Si la priorisation et la planification s’avèrent des techniques formellement justifiées, voire outillées, l’évaluation s’apparente le plus souvent à une forme d’empirisme à l’état pur lorsqu’elle est appliquée aux projets de systèmes d’information. Généralement, dans le meilleur des cas, la première évaluation se réalise à partir de l’expression des exigences lors de l’équivalent d’une phase de Cadrage ; elle s’affine ensuite lors des étapes de Design et se stabilise en principe au début de la phase de Construction du produit. La suite consiste à observer la réalisation, pour tirer les conséquences des écarts éventuels avec les prévisions, et pour apporter les correctifs appropriés (GoNo Go, arrêts d'urgence, tuning et recentrage du développement). Illustration de ce principe figure suivante.

En préalable à l’estimation : la priorisation élémentaire

Une priorisation sommaire basée sur la technique MoSCoW s’effectue souvent de façon empirique lors de l’établissement d’un MVP - le plus souvent déterminé lors d’une session de Story Mapping (cartouche  05 – Consensus produit ou service).  Les lettres majuscules de l'acronyme MoSCoW (anglais) signifient :

  • M - must have : fonctionnalité indispensable, doit être réalisée afin d’assurer la viabilité du produit.
  • S - should have : fonctionnalité essentielle, devrait être réalisée dans la mesure du possible. 
  • C - could have : fonctionnalité de confort, pourrait être réalisée dans la mesure où cela n’impacte pas des priorités supérieures.
  • C - could have : fonctionnalité de confort, pourrait être réalisée dans la mesure où cela n’impacte pas des priorités supérieures. 
  • W - won't have this time but would like in the future : fonctionnalité de prestige, ne sera pas considérée comme un objectif cette fois, mais espérée plus tard (variable d’ajustement).

Note : Lorsque l’estimation sera ensuite effectuée, une autre technique plus formelle (WSJF par exemple) pourra - si nécessaire - être mise en œuvre. WSJF, pour « Weighted Shortest Job First », se traduit par « la plus importante ou la plus courte fonctionnalité d’abord ! ». Cette technique, initiée par DSDM (une méthode issue du RAD) et reprise par SAFe sera évoquée ici même après les techniques d’estimation de charge.

Le principe d’estimation appliqué à Agile

En mode agile pur, le métier travaille en permanence avec l’équipe afin de préciser les spécifications, coder, tester techniquement et valider fonctionnellement « en direct ». Dans ce contexte, la seule estimation initiale utile se limite au global sans détailler obligatoirement les fonctionnalités. En revanche, la compréhension de l’équipe est impérativement suffisante à l’élaboration d’un « contrat projet » (Nombre de sprints, Vélocité, Burn-Up chart) permettant de déterminer le bien-fondé économique du développement (Go ou NoGo). En mode semi-agile, l’évaluation initiale demeure identique, mais il devient nécessaire de détailler (grooming, refinement) les spécifications à embarquer lors des sprints planning.  Il sera profité de cette étape pour réévaluer plus précisément le contenu du sprint backlog. Ces travaux conduiront à un second Go ou NoGo, et éventuellement déclencheront des recherches d’optimisations fonctionnelles ou techniques. À la suite de cette exploration, dans le cas où l’opportunité de la construction du produit se justifierait toujours, le suivi de sa réalisation en regard de l’évolution du contexte amènera alors à « persévérer » ou à « adapter » le développement, ce qui représente d’une certaine manière une autre forme de Go NoGo.

Au-delà de l’estimation basique d’un récit utilisateur

Les estimations - descendantes ou remontantes, composées ou décomposées - ont pour principaux objectifs de tenter de déterminer puis de justifier les coûts de réalisation, donc de conforter à divers niveaux les hypothèses de rentabilité initialement, comme par exemple les values streams dans le cartouche « 03 - Justifications économiques » traitant du lean startup et du lean canevas. Attention, je ne suis pas en train de vous expliquer qu’il est indispensable de calculer tout cela. Je vous matérialise simplement (si l’on peut dire) une partie de la complexité sous-jacente inhérente au contrôle de l’investissement dans ce type de structure. Ou bien, pour employer une métaphore contextuelle « Pour être agile à l’échelle, faites gaffe aux marches ! » 

Pourquoi utiliser le planning poker game ?

Le planning poker permet d’estimer - de manière coopérative mais surtout consensuelle - la complexité d’un produit à développer.  Cette technique, essentiellement empirique, présente deux avantages principaux :  ·  

  • Permettre au métier et à l’équipe d’échanger sur le contenu et la difficulté de réalisation des différentes fonctionnalités du produit. 
  • Obtenir un consensus accepté par l’ensemble des acteurs du développement et engager l’équipe sur la réalisation de ses propres estimations.

Selon Mike Cohn (traduit par Fabrice Aimetti) : Toute l'équipe participe à la réunion d'estimation. Mais cela ne veut pas dire que tout le monde doit estimer chaque élément. Lors du planning poker, les participants ne votent pas pour leurs estimations préférées. L'équipe ne prendra pas sa décision sur l'estimation qui a le plus de votes. On accorde plutôt la crédibilité qui lui est due à chaque estimateur en fonction de son expérience du sujet...  Cela signifie que chaque membre de l'équipe peut estimer, mais que l'équipe donnera plus de poids aux opinions de ceux qui sont plus sachants sur le travail à réaliser. Toujours Selon Mike Cohn, "il y a une dernière raison pour laquelle je suggère que l'équipe entière participe à l'estimation des éléments du backlog produit, surtout avec une technique telle que le planning poker : en procédant ainsi, on augmente le sentiment d'adhésion aux estimations par les membres de l'équipe. Lorsque quelqu'un d'autre estime quelque chose pour vous ou moi, nous ne nous sentons pas engagés par cette estimation. Cela peut être ou non une bonne estimation. Mais si ce n'est pas le cas, ce n'est pas de notre faute. Nous ferons plus de choses pour respecter une estimation que nous avons donnée, plutôt qu'une estimation amenée par quelqu'un d'autre. 

Les unités d’œuvre de l’estimation

Avant le mouvement agile les estimations s’effectuaient directement en jours-hommes ou en points de cas d’utilisation UML, lesquels se trouvaient ensuite convertis en jours-hommes. Certains agilistes, généralement liés à Scrum, ont ensuite souhaité empêcher les comparaisons entre les développeurs ou les équipes ; pour ce faire ils ont inventé les point de complexité relative. Devant les problèmes déraisonnables soulevés par cette approche Mike Cohn proposa la notion d’ideal day. La difficulté rencontrée était le calibrage de cette « journée idéale », car nous le savons tous, ce principe s’avère une chimère. De toute façon, pour obtenir une évaluation réaliste utilisable pour planifier, il fallait ensuite amender l’estimation par un pourcentage de déperdition lié au aléas organisationnels et techniques pouvant varier dans un range de 10 à plus de 50% selon le contexte du développement. Personnellement, je préconisais alors la journée « Non Idéale », c’est-à-dire celle que nous vivons concrètement en fonction du contexte. La bataille entre les tenants des points de complexité et ceux des journées « idéales ou non » dura plus d’une décennie avant que SAFe ne rejoigne ma position en imposant le point de complexité normalisé, seule possibilité de synchroniser les équipes et les trains.

Note : Principe du point de complexité normalisé de SAFe : « Find a small story that would take about a half-day to develop and a half-day to test and validate, and call it a “one”. Estimate every other story relative to that “one” ».  Capacity : « For every full-time developer and tester on the team, give 8 points (for a 10 days sprint).  Subtract one point for every team member vacation day and holiday in the iteration. »

Le point de complexité normalisé revient simplement à renommer la « journée non idéale », et par la même aboutir à ce qui est à l’évidence la seule possibilité raisonnable d’aligner les unités d’œuvre utilisées pour déterminer une charge avec la « capacité » du Sprint à venir, laquelle s’exprime en jours travaillés.

Estimation Agile

Typiquement issu du mouvement Agile, le planning poker permet à une équipe d’estimer la charge de développement d’une fonctionnalité. Lors de cette étape, il sera recherché un consensus entre les membres de l’équipe projet, lesquels estimeront la complexité d’une tâche, en se basant notamment sur une expérience de réalisation similaire.  Voici maintenant, en deux exemples contraires, comment une estimation de ce type fonctionne. 

Note : Comme j’aime beaucoup les illustrations à base de pingouins de Yannick Quenec'hdu je me suis permis un petit emprunt. 

Dans le texte suivant se distingue en gras les différences entre mon expérience de « mise en œuvre équilibrée métier / équipe » et la théorie de la « protection de l’équipe avant tout ». Sans ces distinctions, réexpliquer une fois de plus le Planning Poker Game serait une perte de temps.

L’objectif étant de déterminer le temps de développement d’une fonctionnalité X, vous réunissez l’équipe chargée du travail (dans notre cas 5 personnes nommées A, B, C, D, E). Après explications et précisions fournies par le métier, la question « combien de temps pour développer la fonctionnalité X ? » est posée. 

Premier cas : estimation sans planning poker

Le développeur A évalue le travail à 5 jours alors que B et E ont une estimation beaucoup moins optimiste. Les acteurs C et D pour diverses raisons ne participent pas activement. Bref, c’est A qui annonce en premier « 5 jours ». Cas de figure classique, l’équipe est influencée par la première personne ayant exprimé un avis. Le risque d’erreur devient important, car B et E avaient envisagé cette fonction comme plus complexe et demandant plus de temps de développement. Il est aussi possible d’imaginer qu’une autre personne ait pu penser connaître une solution permettant la réalisation en une seule journée et qu’elle se soit alors abstenue. La déperdition d’informations utiles est alors considérable.

Deuxième cas : estimation en planning poker (avec cartes)

Pour résoudre ces problèmes classiques, vous commencerez par distribuer à chacun un jeu de cartes. Cela peut être un jeu de cartes normal (en utilisant les figures avec la valeur 10 ou en combinant plusieurs cartes), un jeu spécialisé, ou encore une application (ordinateur, téléphone). Généralement les cartes présenteront les valeurs de la suite de Fibonacci (que je n’apprécie pas dans la plupart des contextes). Je ne suis pas opposé à l’idée d’utiliser un 8 et un 2 pour obtenir un 10, et d’ajouter un 20 pour faire un 30, ou toutes autres combinaisons.  

Note : mes cartes de planning poker « low cost » sont disponibles en format pdf (recto/verso) sur mon  site  Il suffit de les imprimer sur un support rigide ou les plastifier, puis de les découper.

L’estimation ne se fera pas en jours / hommes, mais dans une unité d’œuvre nommée « journée non idéale », c’est-à-dire intégrant naturellement l’expérience directe des participants dans un contexte similaire.

Première étape du planning poker

L’équipe se réunit autour d’une table. Après la présentation de la fonctionnalité par le métier, l’animateur pose la question « Combien de temps pour développer selon votre expérience ». Il est éventuellement possible de donner un timing maximum pour la réponse. Dans le cas de fonctionnalités importantes, il peut devenir nécessaire de requérir du métier un complément d’information (carte ?).  Cette fois-ci C et D sont obligés de participer (sauf s’ils ne se sentent pas concernés ou ne disposent pas de la capacité de produire une estimation raisonnablement étayée).  Lorsque l’ensemble des participants a fixé son estimation (en abattant les cartes faces cachées), celles-ci sont retournées. Les deux estimateurs extrêmes (A et C) tentent alors de justifier leurs points de vue divergents. À la suite de cette explication, A réalise, par exemple, qu’il a omis de prendre en considération certains éléments, et C comprend qu’il est peut-être possible de réaliser plus simplement qu’il ne le pensait la fonctionnalité en question. 

Seconde étape du planning poker

Après avoir débattu des divergences observées, toute l’équipe refait une estimation.  À ce point un consensus se trouve généralement obtenu, car le plus souvent les visions convergent au second tour.  Sinon, dans les cas complexes, le processus peut être répété une dernière fois ou bien l’on procède momentanément à une moyenne arithmétique des évaluations. Le but est en effet d’obtenir immédiatement l’estimation d’un périmètre complet. Une évaluation ne nécessite pas une précision absolue, mais raisonnable. Dans les cas insolubles, un point d’action est ouvert et les deux opposés devront réaliser plus tard une étude complémentaire afin de revenir avec des arguments indiscutables permettant de modifier l’estimation « forcée ». 

Note : je réalise en permanence des estimations de type planning poker game exprimées en « journée non idéale » dans de grands comptes. Je peux vous assurer de l’efficacité de cette méthode.

Suite à l’estimation : la priorisation WSJF

WSJF « Weighted Shortest Job First » ou « la plus importante ou la plus courte fonctionnalité d’abord ! ». Cette technique s’appuie sur le principe que toute fonctionnalité non livrée a un coût : The Cost of Delay. L’objectif est donc de le réduire afin de livrer rapidement le maximum de valeur. Le calcul du WSJF prend en compte les critères suivants : 

  • User-Business Value : valeur métier de la fonctionnalité.
  • Time Criticality : criticité de la mise en marché (TTM).
  • Risk Reduction or Opportunity Enablement: prise en compte de la réduction du risque ou de la facilitation du développement d’autres fonctionnalités.
  • Job Size : effort estimé pour le développement de la fonctionnalité.
  • Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement.  Il en résulte que WSJF = Cost of Delay / Job Size.

Plus pragmatiquement, simplement ou rapidement, il suffit de demander au métier d’affecter une valeur business aux fonctionnalités (de 1 à 10 par exemple) et de la diviser par l’estimation du coût de développement ; la valeur obtenue la plus forte indiquera alors la priorité.

Le « contrat projet initial » et la planification des Sprints

Au-delà de l’aspect économique, l’aboutissement concret d’une estimation s’exprime en premier lieu lorsqu’il s’agit de planifier la réalisation du produit (exemple figure suivante).


A ce point nous avons abordé l’estimation de charge, mais pas l’estimation de la « capacity allocation ». La capacité d’un sprint - pour une personne - représente théoriquement le nombre de jours réellement « travaillables ». Pour un sprint de deux semaines, selon qu’il se déroulera au mois de mai ou bien un mois sans jours fériés et sans ponts, la capacité variera énormément. De plus, SAFe recommande de retirer 2 jours à titre de gestion de l’impondérable. Pour finir, lorsque vous planifierez la réalisation des éléments d’un incrément (Load), SAFe vous proposera de ne s’engager (committed objectives) que sur 80% de la capacité restante, et d’utiliser les 20% de marge pour tenter néanmoins de produire un supplément qualifié de « Stretch objectives ». Voila, on en pensera ce que l’on en voudra (éventuellement on adaptera), mais c’est prévu ainsi.

Note : La vélocité réelle mesurée au cours des premiers sprints permettra d’affiner la planification et éventuellement de réviser l’estimation.

L’aboutissement concret d’une estimation s’exprime en second lieu  - lors du suivi des sprints - dans un burn-up chart (graphe d’avancement de la production), dont les éventuels écarts avec la prévision (vélocité théorique initiale) seront explicités par une liste des « freins ou obstacles » tenue en temps réel ainsi que par une métrique des changements demandés par le métier, comprenant abandons ou modifications, même en cours de sprint. Ces aspects seront traités dans les cartouches 10 - Management visuel et 11 - Mode adaptatif maîtrisé.

Conclusion

L’estimation des charges pour la réalisation d’une application, d’un service ou même simplement d’une fonctionnalité est certainement l’une des tâches les plus complexes de la gestion d’un développement. Elle nécessite la collaboration d’experts techniques (team) et d’experts fonctionnels (métier), et est particulièrement dépendante de l’expérience des participants ainsi que de leurs connaissances du contexte organisationnel ou technique.  Pour tenter d'obtenir agilement une évaluation raisonnable, il s’avère préférable d’utiliser le « planning poker game ».  Cette technique aboutit à un affinement de la compréhension du sujet et surtout à une estimation par l’équipe de réalisation - qui du fait s’engage moralement.

Au passage, on s’étonnera d’un détail : le mot « planning » n’a pas grand sens à ce niveau. Le terme exact aurait dû être « estimation poker game » et cette étape précédée d’un « priorisation poker game » (style Moscow) des fonctionnalités souhaitées. Lesquelles auraient été déterminées, par exemple, en design thinking avec les « end users ». Ensuite seraient intervenues les contraintes d’interdépendances fonctionnelles ou techniques (ce que permet de visualiser le program board de SAFe).  Dans cet ordre explicite, la notion de planification en aurait naturellement découlé.   Mais tous ces détails ne sont pas primordiaux ; le vrai problème se situant au niveau de l’unité d'œuvre à choisir. Personnellement, comme je sais que tout finit par se compter en jours, j’utilise la « journée non idéale ». Bien évidemment, ce choix semble trop simple, pratique, raisonnable sans embrouille et surtout insuffisamment en rupture avec ce que souhaitent les tenants de l’ésotérisme agile. Nos apprentis sorciers de la méthode ont donc imaginé cette unité d’œuvre incomparable baptisée « points de complexité relative », dans le sens de « ne pouvant pas permettre de comparaison de productivité entre les équipes ». Bien évidemment cela ne permet pas non plus de planification réelle, donc de synchronisation entre des équipes engagées dans un effort commun. Où se trouve la collaboration et surtout la transparence dans tout cela ? Dans la plupart des projets où j’ai été amené à intervenir, plus de la moitié des équipes - en difficulté ou non - refusaient de livrer un burn-up (ou down) chart. Pour sa part, le métier ne se trouvait que rarement en condition de le produire lui-même faute d’une évaluation initiale du périmètre global et même du MVP… Bonjour la collaboration et la transparence ! Résultat de ces errements, la régression en matière de prédictibilité du pilotage de réalisations est devenue catastrophique. Si seulement tous ces développements se terminaient aussi bien que dans les statistiques actuelles du mouvement anciennement agile …

Note : La vision globale des 12 cartouches de connaissances composant Continuous Sprint 0 se trouve - ici -