Burnup : l'outil indispensable de votre gestion de projet
Débutons par des rappels
L’approche Agile définit des valeurs et des principes permettant de produire et livrer rapidement des fonctionnalités à forte valeur ajoutée.
Elle reprend ce qui fonctionnait bien dans les approches plus classiques :
- Nous recueillons les besoins
- Nous recherchons des idées innovantes
- Nous montons des groupes de réflexion et des ateliers de travail
En revanche :
- Nous ne cherchons plus à tout définir à l’avance
- Nous nous concentrons sur le point de vue de l’utilisateur / du client
- Nous affinons le besoin directement avec les développeurs et les testeurs
Mais surtout :
- Nous travaillons en priorité sur ce qui a le plus de valeur
- Nous adaptons en permanence le périmètre du produit
Scrum : votre conducteur de projet
Il est le cadre méthodologique agile le plus utilisé et respecte parfaitement ces 2 piliers.
Il impose une approche itérative permettant à chaque sprint de réviser les priorités et le périmètre des fonctionnalités à livrer.
Pour suivre l’avancement d’un projet agile Scrum, 2 KPIs sont principalement utilisés : le burndown et le burnup.
Le burndown s’attache à suivre l’avancement de l’équipe sur une itération. Il permet de visualiser l’avance ou le retard pris dans les développements afin de prendre les mesures adaptées, comme par exemple la prise en compte d’une fonctionnalité supplémentaire ou au contraire le retrait d’un item.
Le burnup, quant à lui, offre une vision plus globale. Il peut être utilisé pour piloter une version majeure appelée « release » ou bien le projet dans son ensemble.
Il présente l’avancement appelé le « réalisé » c'est à dire le travail accompli par rapport à l’objectif que nous nommons le « périmètre ». Son intérêt réside également dans la mesure de la prédictibilité. Il permet de visualiser l’atterrissage en fonction des variations de périmètre, de l’avancement et des projections.
Comme tout graphique, l’objectif c’est la communication. Le burnup permet de partager les informations d’avancement et de variation de périmètre au sein de l’équipe mais aussi et surtout en dehors de l’équipe (MOA, client, parties prenantes).
Pour rappel, l’équipe Scrum regroupe le Product Owner, le Scrum Master et l’équipe de développement.
Comment le mettre en oeuvre ?
Pour construire un burnup, c’est très simple :
- Sur l'axe des abscisses, on liste les sprints
- Sur celui des ordonnées, 2 variantes
1) Production de valeur
Un burnup est normalement basé sur la « business value ». Cette valeur métier, estimée par le Product Owner, mesure le gain/le bénéfice apporté par une fonctionnalité.
Le périmètre initial correspond alors à la somme des valeurs métier de toutes les fonctionnalités à réaliser.
Si la valeur atteinte est jugée suffisante, il est tout à fait possible de stopper le projet en l’état.
Cette possibilité, propre à l’approche agile, s’oppose à l’approche classique qui impose la fourniture de l’intégralité du périmètre défini, dans les temps impartis et dans le strict respect du budget établi initialement. Ce qui, il faut le concéder, n’arrive que très rarement.
En vert, la courbe « théorique » d’un projet pour lequel la valeur produite est extrêmement importante, et ce dès le démarrage.
La courbe rouge présente une vision plus réaliste, qui tient compte de la nécessaire montée en charge progressive de l’équipe de développement.
2) Respect du périmètre
Lorsque la valeur métier n’est pas évaluée (ou pas systématiquement), ce qui arrive plus souvent qu’on ne le croit, on peut s’appuyer sur la notion de « story point ». Cette estimation, réalisée par l’équipe de développement, mesure l’effort nécessaire pour réaliser la fonctionnalité.
Le périmètre initial correspond alors à la somme des points d’effort de toutes les fonctionnalités à réaliser.
En complément, si la date de livraison souhaitée est connue, nous pouvons faire apparaître un jalon sur le graphique pour matérialiser cette deadline.
La mise à jour
À la fin de chaque itération, les valeurs métier (ou les points d’effort) des fonctionnalités livrées viennent s’ajouter au total des fonctionnalités précédemment livrées.
Toute modification du périmètre, à la hausse ou à la baisse, selon l'ajout ou le retrait de fonctionnalités, est également reportée.
Comment l'exploiter ?
La confrontation de l’avancement et du jalon peut donner lieu à des arbitrages.
Pour tenir une deadline, il peut ainsi être nécessaire de retirer certaines fonctionnalités. À l’inverse, toute évolution du périmètre impactera le respect des jalons et la durée du projet.
Quelques exemples de réflexion induite par la lecture du graphique :
- Si le périmètre augmente, est-ce que nous tenons toujours le jalon ?
- Quelle est notre marge de manœuvre ? Peut-on ajouter 1 ou 2 fonctionnalités ?
- À l’inverse, le périmètre peut-il être revu à la baisse pour respecter la deadline ?
- Dans le cas contraire, est-il possible de revoir le planning ?
NB : si le périmètre n’évolue pas, on peut se demander : ce projet est-il vraiment agile ?
Exemple 1
Ce que nous pouvons analyser en observant ce burnup :
- L’équipe a rapidement pris le rythme et même de l’avance
- La bonne vélocité de l’équipe a permis d’intégrer des fonctionnalités supplémentaires
- La livraison à la date souhaitée va être difficile sans révision du périmètre à la baisse
Exemple 2
Ce que nous pouvons analyser en observant le burnup ci-dessous :
- 2 jalons de livraison sont identifiés (V1 / V2)
- La première version concerne le MVP, la seconde intègre le reste des fonctionnalités
- Le périmètre du MVP a été enrichi (sprint 3) avant d’être révisé (sprint 5)
- Le périmètre initial du MVP était parfaitement défini
- La vélocité réelle de l’équipe est inférieure aux prévisions
- La vélocité de l’équipe est en revanche relativement constante (meilleure prédictibilité)
- Le périmètre de la V2 a beaucoup augmenté. Là encore, un retrait de fonctionnalité a été nécessaire pour tenir le planning
- Une courbe de prévision est ajoutée pour mieux visualiser l’atterrissage au regard de la vélocité réelle de l’équipe. Afin de tenir compte de l’incertitude, une variation haute/basse peut être ajoutée à la prévision.
Que retenir du burnup ?
Rapide à initialiser et facile à alimenter, le burnup est un outil très puissant.
Il permet de suivre l’avancement d’un projet de manière extrêmement visuelle et l’interprétation des courbes ne laisse pas de place au doute. À tout moment, nous visualisons l’atterrissage et la cohérence globale entre le périmètre, la vélocité de l’équipe et le planning. Les arbitrages sont clairement simplifiés.
Point de vigilance malgré tout, sa lecture peut nécessiter des explications si le public visé n’est pas familiarisé avec l’outil.
Le conseil de notre expert
Si vous le pouvez, initialisez les deux types de burnup. De cette manière, vous pourrez à la fois vous assurer que vous travaillez bien en priorité sur ce qui a le plus de valeur et adapter en permanence le périmètre du produit à l’avancement de l’équipe et aux contraintes planning.
Bien évidemment, il y a d’autres indicateurs intéressants à mettre en place :
- Le burndown pour le suivi du sprint
- Le radar pour le suivi de l’équipe (engagement, motivation, satisfaction…)
- Le Niko Niko pour le suivi de l’humeur au quotidien
- Les anomalies et la qualimétrie pour le suivi de la qualité du produit
- ...
Mais si vous devez mettre en place un premier indicateur, faites moi confiance, c’est le burnup.
Et souvenez-vous, ne faites pas de l’agile, soyez « agile » : faites simple et améliorez-vous !
Christophe,
Expert technique
