Release burn up et cône d’incertitude

Prédisons l’avenir … surtout s’il n’est pas rose ainsi nous pourrons nous adapter!

Introduction

Parfois on entend, « on est Agile alors on ne prévoit pas … ». Personnellement cela me fait dresser les cheveux sur la tête. Être Agile signifie être capable de s’adapter aux changements s’ils apportent plus de valeur, il faut donc connaitre d’où l’on part. Alors oui, en Agile on a un plan, et oui il change. On aimerait qu’il se déroule sans accroc, ce n’est pas le cas, il faut savoir s’adapter ! Ce court sujet n’est pas toujours repris dans les formations, c’est pourquoi je vous propose cet article.

Le release burn up

Appliquer des principes Agile, c’est accepter que l’on ne sache pas tout au début du projet, et par conséquent il va falloir être capable de s’adapter au fur et à mesure des apprentissages. On les voudra donc le plus tôt possible, d’où l’approche incrémentale mais qui n’est pas le sujet de ce billet. Pour savoir si on avance dans la bonne direction, on ne peut pas seulement suivre le plan, on doit suivre la valeur produite.

Alors peut-on prédire la valeur produite ? Pour la même raison, non. Car encore une fois, on ne sait pas tout au début. Le PO, Les PM selon la dimension du produit vont être responsables de maximiser cette valeur produite, en choisissant en permanence ce qui apporte le plus de valeur et ainsi ils vont définir leur backlog de sujets à réaliser. Mais alors comment on se dirige ?

En fonction de notre capacité à réaliser cette backlog ! Nos PO, PM définissent une backlog qui amènera de la valeur et l’équipe estime de manière relative plus ou moins finement (rappelons que si on passe beaucoup de temps à estimer, on produit d’autant moins …)

Imaginons nos PO, PM avec une backlog estimé à 300 points, on pourrait se demander quand il sera livré. Nous pouvons le déterminer en fonction de la vélocité constatée des équipes. Sur le schéma 1 nous en sommes au Sprint 7 et nous avons l’historique de chaque sprint en vert. Nous avons aussi fait apparaitre le contenu du MVP (minimum viable product) en termes de point d’effort, la courbe noire. On peut voir que le contenu s’est réduit au cours du sprint 4, du à de l’affinage ou des renoncements.

En fin de sprint 7, Le PO ou PM espère livrer en fin de sprint 9. Mais en serons-nous capable ? Le trait rouge représente le jour de demo, en fin de sprint 9. Nous considérons dans notre « release » tout le contenu des 9 premiers sprints.

Nous pouvons alors extrapoler avec la vélocité moyenne de l’équipe sur les 7 premiers sprints et même en enlevant les jours fériés.

Le verdict tombe : nous ne pourrons pas livrer le contenu en sprint 9 car nous n’aurons pas croiser la courbe du MVP. Mais nous pouvons voir que nous pourrons livrer au cours du sprint 11. Personnellement je ne prendrais pas cet engagement. Notre façon de faire des estimations relatives d’équipes est rapide et permet le partage et l’engagement commun mais n’est pas précise. Quelle marge pouvons-nous prendre? Nous pouvons prendre celle que l’on connait, c’est-à-dire selon le vécu de notre équipe.

Le cone d’incertitude

Dans nos historiques de sprint, nous allons rechercher la vélocité la plus lente (courbe rouge) et la plus rapide (courbe verte) et les faire apparaitre sur notre diagramme :

Ainsi se dessine le cône d’incertitude de livraison.

Remarquer que la vitesse la plus lente est pris sur notre premier sprint, et qu’elle ne s’est jamais reproduite, nous pourrions donc choisir de ne pas prendre cette vitesse dans notre projection : Les individus et les interactions avant les process et les outils comme dirait un certain manifeste.

Ce diagramme nous permet de prédire qu’au plus tard nous livrerons le MVP en cours du sprint 13 et au mieux dans le 9 (sans grands évènements externes). Nous pourrions nous aider de ces données pour prédire qu’après le sprint 9 nous aurons le MVP ou nous n’aurons que les 100 premiers points du MVP, soit les 100 premiers points les plus importants.

Cette méthode fonctionne pour une équipe comme pour un train (au sens SAFe), il faut « simplement » avoir une vélocité stable c’est-à-dire une certaine prédictibilité.

Ce sera le rôle du scrum master ou du RTE pour un train SAFe d’entrainer son équipe ou son train sur cette voie.