Rangez vos jetons de poker ! Loin de l’ambiance feutrée des casinos monégasques, la simulation de Monte-Carlo est la botte secrète des Product Owners de Kanbios. En effet, elle permet de planifier les dates de livraison de vos projets au Sprint près. Comment ? En utilisant la statistique pour apporter de l’objectivité dans une pratique Agile plutôt subjective : l’estimation de l’effort.
De la gestion de l’incertitude dans un projet Agile…
« À quelle dates seront livrés les éléments ? » En Agile, la réponse à cette question ressemble étrangement à une équation mathématique. Le Product Owner va mettre en regard deux estimations :
- l’effort à fournir par l’équipe pour réaliser toutes les tâches inscrites dans la Roadmap produit. Cet effort est exprimé en Story points
- la vélocité de l’équipe, c’est-à-dire le nombre de Story points réalisés par l’équipe en un Sprint
En divisant l’effort par la vélocité, le Product Owner obtient le nombre de Sprints nécessaires pour développer le produit final. Il connait par conséquent la durée du projet et peut planifier les différentes livraisons sur cette dernière. Facile, non ?
Cette méthode serait effectivement simple, si l’effort, la vélocité ou la durée de Sprint étaient des données fixes et constantes quelle que soit la configuration du projet. Or ce n’est pas le cas. Ce sont des données relatives qui sont intrinsèquement liées à la complexité du projet. Elles dépendent aussi des membres de l’équipe de production, notamment leur expérience et leur capacité à travailler ensemble.
La durée d’un Sprint ou la vélocité de l’équipe sont des données plutôt aisées à stabiliser en début de projet. La durée d’un Sprint est fixée en fonction du contenu de la Roadmap produit. Quant à la vélocité de l’équipe, il s’agit d’une moyenne calculée après plusieurs Sprints. Cette moyenne sert de référence tout au long du projet.
Par contre, la notion d’effort est tributaire de la perception du projet par l’équipe. Le manque d’informations en lancement de production, une compréhension partielle des attendus du projet, l’expérience des personnes sur des projets similaires… De nombreux facteurs peuvent pousser l’équipe à sur-estimer ou sous-estimer le nombre de Story points associé à une tâche de Roadmap. Ces estimations incertaines peuvent avoir un impact conséquent sur la planification des livraisons. Et ce, en faussant le calcul du nombre de Sprints nécessaires pour développer le projet.
Souvent, le Product Owner ajuste la planification des livraisons en appliquant un coefficient « erreur d’estimation de l’effort » au calcul du nombre de Sprints. Toutefois, cet ajustement peut se révéler insuffisant pour éviter les décalages de livraison. Notamment lorsque l’équipe se retrouve à produire plus de Story points qu’initialement prévu. Cette situation donne lieu à des échanges difficiles avec les clients. Surtout lorsque ces derniers ont planifié leurs propres actions en fonction du planning de livraison prévisionnel. A ce titre, il est intéressant de noter que l’enjeu de la planification de livraison n’est pas uniquement opérationnel mais il est également communicationnel.
…à son intégration dans le projet grâce à la simulation de Monte-Carlo
L’incertitude sur le déroulement réel du projet fait fluctuer le nombre de Story points associés à une tâche. Par conséquent le nombre de Storypoints pour l’ensemble de la Roadmap. Toutefois, il existe un outil statistique utilisé en finance qui permet de calculer la valeur d’un produit en fonction de la fluctuation aléatoire de la valeur de ses composants dans le temps : il s’agit de la simulation de Monte-Carlo. Et c’est précisément cet outil que les Product Owners de Kanbios utilisent dans le cadre de la planification de livraison.
Comment cela fonctionne-t-il ? Dans un premier temps, le Product Owner demande à l’équipe d’estimer l’effort pour chaque tâche de la Roadmap. Il intègre ces valeurs dans un fichier de simulation et il les additionne une première fois, pour obtenir l’effort global selon l’équipe.
Plusieurs centaines de simulations de Monte-Carlo sont lancées à partir de ce fichier. Pour chaque simulation, l’algorithme va modifier le nombre de Storypoints de chaque tâche de façon aléatoire, selon 3 hypothèses :
- 1 « la tâche a été bien estimée par l’équipe » : le nombre de Story points de la tâche reste identique ;
- 2 « la tâche a été sous-estimée par l’équipe » : le nombre de Story points de la tâche augmente ;
- 3 « la tâche a été sur-estimée par l’équipe » : le nombre de Story points de la tâche diminue.
Le résultat des simulations est inséré dans un histogramme, avec en abscisses, des plages de résultats de simulation (exprimés en ordres de grandeur de Story points), et en ordonnées, le nombre de simulations qui ont donné un résultat compris dans la plage désignée. Par exemple, dans cet histogramme, on observe que 80 simulations ont abouti à un résultat compris entre 108 et 110 Story points.
Toutefois, c’est la répartition de la majorité des résultats des simulations qui est l’élément le plus intéressant dans cette représentation des résultats. Toujours dans cet exemple, on observe que la majorité des simulations ont abouti à un résultat inférieur à 122 Storypoints. Pour un Product Owner Kanbios, cela signifie que l’équipe n’aura vraisemblablement pas à produire plus de 122 Story points pour livrer ce projet, et ce, quels que soient les erreurs d’estimation réelles faites par l’équipe ou bien les événements qui peuvent perturber la progression du développement du produit.
Une fois la valeur de l’effort stabilisée, le Product Owner n’a plus qu’à évaluer la vélocité de son équipe. Il calcule ensuite le nombre de Sprints nécessaires pour développer le produit. Il peut ainsi proposer un planning de livraison plus réaliste.
Quels sont les apports de la simulation de Monte-Carlo dans un projet Agile ?
Au-delà du gain de précision dans la planification des livraisons, l’utilisation de la simulation de Monte-Carlo présente deux avantages.
D’une part, elle permet d’alerter le Product Owner sur un éventuel défaut de découpage de la Roadmap produit. En effet, un trop grand écart entre les résultats de simulations indique qu’une tâche dans la Roadmap est tellement conséquente qu’elle peut faire basculer l’intégralité du résultat de la simulation selon l’hypothèse retenue par l’algorithme (estimation juste, sur-estimation, sous-estimation). Dans ce cas, il appartient au Product Owner et à l’équipe d’analyser plus en détail les raisons de la présence de cette tâche « obèse ».
D’autre part, le partage de l’histogramme de résultats permet , en un visuel, de rappeler aux parties prenantes du projet qu’estimer et planifier des livraisons consiste à formuler des hypothèses sur le déroulement d’un projet et non formuler des vérités. Ainsi, les planifications de livraison en Agile mettent en lumière non seulement l’efficacité d’une équipe de développement mais surtout la façon dont elle intègre la gestion des risques associée au projet dans son activité au quotidien.
En résumé
- Chez Kanbios, nous utilisons la simulation de Monte-Carlo pour planifier plus précisément les livraisons de produits développés en Agile.
- Il s’agit d’une méthode d’évaluation statistique qui intègre dans ses résultats la part d’incertitude liée à l’estimation de l’effort pour chaque tâche de la Roadmap produit.
- Cette méthode met en lumière le point majeur de la planification : estimer une date de livraison consiste à formuler une hypothèse sur le déroulement du projet et non énoncer une vérité.
Envie d’aller plus loin ?
Si vous souhaitez devenir un as de la planification Agile et apprendre à utiliser la simulation de MonteCarlo dans votre propre activité, nous vous recommandons de consulter le webinaire de Jules Aumand, Product Owner chez Kanbios et « trader » de la planification de projets à forte valeur ajoutée !
Et si vous souhaitez transformer votre idée en véritable projet, prenez rendez-vous avec nos experts en complétant le formulaire accessible ci-dessous !
