Nous touchons au but : nous avons une équipe fière et disponible 2000 jours par an et à 100% de sa capacité tout au long de la roadmap projet.
Reste à chiffrer / évaluer en jours de travail les éléments proposés dans la roadmap.
Il existe plusieurs manières de chiffrer : Use Case Points / Story Points par exemple. Elles sont toutes empiriques et donc basées plus ou moins sur l’expérience.
J’insiste lourdement en rappelant que toutes sont une tentative rassurante d’expliquer de manière rationnelle qu’une part d’incertitude existe dans la feuille de route : les éléments à 18 mois ne sont pas connus de manière assez précise pour être tous intégralement chiffrés.
Donc parfois, le « doigt mouillé », le hasard ou l’interprétation incantatoire de signes divinatoires pourrait donner d’aussi bons résultats : souvenez-vous du poulpe lors de la dernière Coupe du Monde. Son sort, lorsqu’il s’est finalement trompé, n’est pas loin du sort réservé à l’équipe ou au Product Owner, au moins en termes de confiance perdue vis-à-vis des clients internes ou externes.
Il existe plusieurs règles de bon sens encore une fois au sujet des chiffrages :
- Ce qu’il y a à faire dans un produit n’est pas répétitif et n’est par définition pas déjà dans le produit : c’est toujours un petit projet en soi avec son lot d’incertitudes
- Une ligne dans un fichier Excel a tout en commun avec une autre ligne.
Comment montrer / expliquer qu’elles sont plus grosses ou riches d’un point de vue fonctionnel ? - Pour faire diminuer l’incertitude, il faut détailler les choses à faire
- Plus vous détaillez ce que vous avez à faire, plus vous allez considérer que c’est un gros travail : plus vous découpez ce qu’il y a à faire, plus le chiffre obtenu en termes de temps de travail est gros
- Celui qui chiffre c’est celui qui fait sinon il se sent moins concerné : en clair, chiffrer c’est prendre un risque de se tromper, il vaut mieux « mouiller » le plus de monde possible
(a minima l’équipe)
Quelle est la bonne méthode d’évaluation d’une roadmap projet ?
Comment faire pour avancer me direz-vous ? Il faut choisir en commun une méthode, l’apprendre, la pratiquer et se donner du temps pour se faire confiance, voir des résultats et réadapter la méthode ou les outils. (N.B. : je suis conscient que le temps est parfois l’élément qui va manquer, dans ce cas, reprendre les activités divinatoires habituelles pour le chiffrage et PRIER ! ? Cela devrait être tout aussi efficace in fine et libérer du temps de cerveau disponible des équipes mises à chiffrer en urgence… Pour les plus sceptiques, encore une fois, je rappelle que tout projet est un pari sur l’avenir avec un risque à évaluer.)
Je propose de choisir une méthode empirique (elles le sont toutes plus ou moins je vous le rappelle) basée sur les tailles de T-Shirt (« T-Shirt sizing »). Dans cette méthode, on attribue une valeur à chaque taille de T-Shirt et ensuite, il ne reste plus qu’à balayer les lignes du fichier Excel pour attribuer une taille à la chose à faire.
Il peut y avoir quelques préférences, adaptations locales : il y a parfois un besoin de séparer complexité de taille « durée » du développement. Mais ce n’est qu’un débat d’experts inutile à mon avis…
Souvent également, les équipes ne chiffrent que le travail des développeurs.
Normal me direz-vous ? Souvent, c’est à eux qu’on demande généralement de s’engager et on considère que tout n’est ensuite qu’un facteur de leur travail : par exemple, dans mon cas, précédent d’équipe, si un développeur dit qu’il lui faut 60 jours pour faire une fonctionnalité, il ne faut pas oublier de « réserver » 10 jours de travail du PO et 30 jours de travail des business analysts et de la QA. Gardons cette hypothèse pour la suite de ne chiffrer que ce que font les développeurs.
Voici par exemple, une échelle que nous pourrions utiliser :
Taille | XXXL | XXL | XL | L | M | S | XS |
---|---|---|---|---|---|---|---|
Temps (j) | 500 | 200 | 100 | 50 | 20 | 10 | 5 |
Echelle | 5 à 6 mois | 1 à 3 mois | 1 mois | 1 Sprint |
Vous remarquerez que l’expression du temps en jours de capacité nécessaires s’inspire d’une version simplifiée de la suite de Fibonnaci ou d’une règle qui exprime globalement qu’une taille est le double « en gros » de la précédente.
L’échelle donne deux informations :
- A partir de « L » et en-dessous, c’est suffisamment petit pour être candidat d’un sprint prochain (rappelez-vous que l’équipe peut absorber 100 jours de travail dont 60 jours pour les développeurs => donc la taille est ok jusqu’à « L ». Cela ne vous empêchera pas d’avoir quelques « L » finalement un peu gros à faire rentrer…)
- Au-dessus de « L », pas possible de l’imaginer dans un Sprint : ce n’est pas assez détaillé à ce stade pour que l’équipe soit en mesure de le faire. L’échelle dans ce cas, vous donne un équivalent : un sujet en XXXL va prendre la moitié de l’année de l’équipe => vous ne pourrez en faire que 2… Généralement dit comme cela, cela fait réfléchir sur ce genre de sujet un peu gros ou fonctionnalité « YaKaFauKon »
Donc il ne vous reste plus qu’à faire une série de grandes messes auxquelles vous allez convier les développeurs (ou l’un deux) pour chiffrer enfin dans la joie et la bonne humeur de votre roadmap.
Vous avez bien travaillé et vous devriez obtenir un chiffre qui ne vous satisfait pas…
Par exemple, vous vous rendez compte qu’il y a l’équivalent de 6 000 jours à faire et que vous n’avez que 2 équipes à capacité de 2000 jours par an mais 1200 jours de dev… Je l’aborde pour l’aspect rhétorique mais le cas où il n’y a pas assez de travail pour l’équipe n’existe pas (ou alors le produit que vous fabriquez est déjà mort).
A propos de l’auteur : Benoît Fillon
Lisez aussi :
Comment faire une roadmap 1/5 : Une roadmap c’est quoi ?
Comment faire une roadmap 2/5 : pour qui et pour quand ?
Comment faire une roadmap 3/5 : La capacité de l’équipe c’est quoi ?