En gestion de projet classique, on utilise le pourcentage d’avancement du projet pour mesurer son avancement et vérifier s’il est dans les temps ou pas.
Mais avec les méthodes agiles, comment fait-on ?
On n’utilise pas les jours-hommes mais les points d’efforts comme unité de mesure. On accepte que les estimations soient approximatives. Et on a un périmètre évolutif.
C’est le cocktail parfait pour rendre impossible tout calcul du pourcentage d’avancement du projet. Et c’est une bonne chose !
Dans cet article, on va voir comment le burnup chart permet de suivre l’avancement d’un projet agile dans sa globalité, comment le lire et aussi comment le créer.
Qu’est-ce qu’un burnup chart ?
Le burnup chart est un outil de reporting agile qui représente visuellement l’avancement de l’équipe agile sur plusieurs itérations, en parallèle avec le périmètre du projet.
Cet outil permet d’estimer une date de fin prévisionnelle pour un produit, une feature ou une release.
Ce graphique se construit en mettant sur l’axe des abscisses (axe horizontal) les différentes itérations, et sur l’axe des ordonnées (axe vertical) le total des points d’efforts nécessaires pour réaliser l’intégralité du backlog de produit.
On trace alors deux courbes :
- La première représente l’évolution du périmètre du projet, à la hausse ou à la baisse.
- La seconde représente la vélocité de l’équipe, itération après itération.
Le burnup chart est un outil très pratique pour apporter de la prédictibilité à l’équipe Scrum ainsi qu’aux parties prenantes du projet, et permet de visualiser d’un coup d’œil le travail accompli par l’équipe et les éventuels problèmes de périmètre.
Exemple de burnup chart
Burnup chart vs burndown chart : quelles différences ?
Le burnup chart est un graphique montrant le travail accompli en comparaison au travail à réaliser. Le burndown chart montre le reste à faire par rapport à un périmètre donné. A périmètre identique, ces deux graphiques montrent la même information.
Il est donc crucial pour utiliser ces deux outils de reporting agile de faire varier le périmètre.
- Le burnup chart.
On l’utilise principalement pour suivre la vélocité de l’équipe sur plusieurs itérations ainsi que l’avancement d’un produit, d’une feature ou d’une release sur plusieurs sprints. - Le burndown chart.
On utilise principalement le burndown chart pour montrer l’avancement de l’équipe de développement en cours de sprint, et le « reste à faire » d’ici à la fin de l’itération pour atteindre l’objectif de sprint.
Pour aller + loin : Consultez cet article pour découvrir toutes les différences entre un burnup chart et un burndown chart, et dans quel cas les utiliser.
Avantages et intérêt du burnup graph
Pourquoi utiliser le burnup graph ? ça ne fait pas un peu redondance avec le burndown chart ?
Justement non. Utiliser un burnup chart apporte de nombreux avantages en gestion de projet agile. En voici les principaux :
- C’est un outil de reporting.
Le burnup chart est un outil de reporting qui peut être partagé en dehors de l’équipe Scrum, avec les parties prenantes du projet. Il rassure, permet de suivre l’avancée de l’équipe et donne de la visibilité sur le projet agile. - Améliore la prédictibilité de l’équipe.
Le burnup chart permet de prédire la date de fin prévisionnelle d’un projet, en fonction de la vélocité de l’équipe et du périmètre à réaliser. - Donne de la visibilité au-delà d’une itération.
Cet outil est également utilisé pour suivre l’avancement du travail accompli dans le cadre de feature ou de release d’un produit. Il donne de la visibilité sur plusieurs itérations, passées et à venir. - Montre les problèmes de périmètre et de backlog.
Si le périmètre évolue subitement à la hausse, et que l’équipe a du mal à suivre derrière, le burnup chart permet de visualiser cette problématique. Il donne ainsi une vision d’ensemble de la problématique, plutôt que de se concentrer uniquement sur la vélocité de l’équipe. - Permet d’être proactif.
Représenter graphiquement la courbe d’avancement de l’équipe et le périmètre à réaliser permet d’être proactif et de prendre rapidement les décisions qui s’imposent. Par exemple, si il reste 3 itérations avant de livrer une release, on peut voir rapidement si l’équipe sera en mesure de livrer l’intégralité du périmètre ou non. On peut ainsi le revoir à la baisse si besoin pour tenir la livraison de la release.
Qui fait le burnup chart ?
Le burnup chart est un graphique réalisé par l’équipe Scrum, et plus particulièrement le Product Owner. Il est mis à jour à la fin de chaque sprint pour tenir compte de la vélocité de l’équipe du dernier sprint et de l’évolution du périmètre du projet.
Toutefois, l’équipe Scrum peut décider de donner cette responsabilité non pas au product owner, mais à l’équipe de développement.
A mon sens, c’est plus logique que le product owner garde la main sur l’outil. Cela participe en effet à la construction de la vision produit, qui est portée par le PO (Product Owner).
Quand doit-on faire un burnup chart ?
Le burnup chart est créé à la fin du premier sprint afin de représenter le travail accompli et de le comparer au travail à réaliser. Il est par la suite mis à jour à chaque fin de sprint pour suivre l’avancement de l’équipe Scrum.
Quelle échelle utiliser pour un burnup chart ?
On peut représenter le périmètre à réaliser sur le projet agile de deux façons :
- Le total des points d’efforts.
Cela implique de faire une estimation de l’ensemble des éléments contenus dans le product backlog. On additionne la somme des story points obtenus et on les reporte sur le burnup chart. - Le nombre de user stories.
Plus simple, on compte simplement le nombre d’éléments présents dans le product backlog, puis on reporte la somme sur le burnup graph.
Personnellement, je préfère utiliser les points d’efforts comme échelle pour le burnup chart, car cela représente plus justement la valeur business qui est associée aux user stories.
Mais si vous débutez l’agilité avec votre équipe ou que vous voulez aller vite, vous pouvez dans ce cas utiliser comme échelle le nombre de user stories.
Enfin, certaines personnes utilisent comme échelle la valeur business directement, afin de voir à partir de quand le travail accompli ne fait qu’augmenter de très peu la valeur business produite. Il s’agit d’une technique avancée permettant de savoir quand arrêter un projet agile.
Comment lire un burnup graph ?
Ce qui est intéressant avec le burnup chart, c’est qu’on peut en déduire beaucoup d’informations à partir des deux courbes représentées : l’évolution du périmètre et le travail accompli.
On peut ainsi visualiser les évolutions à la hausse ou à la baisse (plus rare) du périmètre du product backlog. Je rappelle qu’une évolution du périmètre est normal et souhaitable en agilité.
On peut également observer l’évolution de la vélocité de l’équipe au fur et à mesure de l’équipe, et voir si elle est constante ou si au contraire elle est en dent de scie. Dans ce dernier cas, ce serait intéressant de creuser pour comprendre pourquoi.
Enfin, on peut également prédire une date de fin prévisionnelle pour livrer un produit, une feature ou une release. C’est le moment où les deux courbes se croisent.
Par extension, on peut également voir si l’équipe sera en mesure de traiter l’intégralité du périmètre avant la date cible de livraison ou pas. Dans le second cas, cela laisse la possibilité d’adapter le périmètre de l’équipe si l’on ne souhaite pas décaler la livraison.
Pour aller + loin : Consultez cet article pour découvrir comment analyser de manière détaillée un burnup chart. J’y aborde tous les cas de figure possible, et les enseignements que vous pouvez en tirer.
Comment réaliser un burnup chart ?
Le burnup chart se construit de la façon suivante :
- Il est initié au début du projet, de la feature ou de la release.
- L’équipe Scrum choisit le périmètre à intégrer, puis estime les points d’efforts nécessaires pour atteindre l’objectif.
- Le product owner trace alors une première courbe, représentant la somme des story points des éléments du product backlog. C’est l’objectif à atteindre.
- A la fin de chaque sprint, il calcule la vélocité de l’équipe par rapport à l’incrément de sprint, contenant des éléments 100% terminés et respectant la definition of done.
- il reporte ensuite l’avancée de l’équipe sur une seconde courbe, et ajoute la vélocité du sprint terminé à la somme des précédents.
Exemple de burnup chart
Pour aller + loin : Consultez cet article pour construire pas à pas un burnup chart de qualité.
Peut-on utiliser un burnup chart avec d’autres méthodologies que Scrum ?
Le burnup chart n’est pas un outil réservé au framework Scrum. Vous pouvez l’utiliser avec d’autres méthodes agiles telles que Kanban, XP (Extreme Programming), LeSS, SAFe, ou encore Lean. Cet outil peut également être utilisé en gestion de projet traditionnel pour suivre l’avancée du projet.
Le principe reste le même : représenter de manière simple et visuelle le travail accompli par l’équipe, et le comparer avec ce qui doit être réalisé afin d’avoir une date de fin prévisionnelle.
Limites du burnup chart
Toutefois, il existe des limites au burnup chart qu’il est bon de connaître pour ne pas se faire avoir.
- Nécessaire d’avoir un périmètre connu pour tracer le burnup chart.
Bien que le périmètre d’un projet varie en mode agile, il est nécessaire de partir d’un périmètre « de base », connu et estimé, pour tracer un burnup graph. - A périmètre identique, il donne les mêmes informations qu’un burndown chart.
Dans un cas la courbe monte pour représenter le travail accompli. Dans l’autre, la courbe descend pour représenter le reste à faire. Si on prend le même périmètre pour les deux graphiques, alors l’information représentée est exactement la même. - Représenter les points d’efforts nécessite d’avoir réalisé une estimation de l’ensemble des éléments du product backlog.
Pour tracer un burnup chart, il faut connaître le total des points d’efforts du product backlog. Des techniques telles qu’extreme quotation permettent d’estimer « grossièrement » plusieurs dizaines de user stories en un temps record. C’est un bon point de départ. - Il montre les problèmes mais ne les résout pas.
Le burnup chart permet de visualiser les problèmes de périmètre ainsi que les problèmes d’équipe. Mais il faut faire quelque chose de cette information, pour régler le problème définitivement. En somme, un burnup graph, ce n’est pas magique.
Source : Article « Feel the burn : getting the most out of burn charts », par George Dinwiddie