Le Burnup Chart : le guide complet pour maîtriser l’avancement et démasquer le Scope Creep en Agile

Dans le monde de la gestion de projet agile, la transparence et la visibilité de l’avancement sont indispensables. Alors que de nombreuses équipes s’appuient traditionnellement sur le Burndown Chart pour mesurer le travail restant, cet outil présente parfois des limites lorsque le périmètre du projet évolue en cours de route. C’est ici qu’intervient le Burnup Chart (ou graphique d’avancement cumulé). Complémentaire et souvent plus révélateur, le Burnup Chart offre une lecture limpide de ce qui a été accompli tout en mettant en lumière les variations du périmètre global. Bien que ni le Burnup Chart ni le Burndown Chart ne soient prescrits de manière stricte par le Scrum Guide officiel créé par Jeff Sutherland et Ken Schwaber — ce dernier exigeant simplement de suivre la progression vers les objectifs sans imposer d’outil graphique particulier —, le Burnup s’est imposé comme une pratique incontournable au sein du framework Scrum et des méthodes agiles.

Le principe du Burnup Chart : deux courbes qui montent

Contrairement au Burndown Chart dont l’unique courbe de « reste-à-faire » descend vers zéro au fil du temps, le Burnup Chart trace deux courbes distinctes qui progressent vers le haut au fur et à mesure que le projet avance :

• L’axe horizontal (X) : représente le temps, découpé en jours, en semaines ou, plus couramment dans le cadre Scrum, en Sprints.
• L’axe vertical (Y) : mesure la quantité de travail, exprimée en Story Points, en nombre de tâches ou en heures.
• La ligne de portée totale (Scope) : située en haut du graphique, elle représente le volume total de travail planifié pour le Sprint, la release ou l’ensemble du produit.
• La ligne de travail complété (Cumul) : elle démarre au bas du graphique et monte à chaque fois que des éléments du Backlog sont entièrement réalisés (conformes à la Definition of Done).

L’objectif visuel du Burnup Chart est simple : la courbe de travail complété doit rejoindre la ligne de portée totale à la date cible prévue.

L’avantage clé face au Burndown Chart : démasquer le Scope Creep

Le principal défaut du Burndown Chart réside dans sa manière de synthétiser l’information. Dans un Burndown Chart, si une équipe produit 15 Story Points de valeur pendant un Sprint mais que le Product Owner ajoute simultanément 15 Story Points de nouvelles fonctionnalités urgentes dans le périmètre, la courbe du reste-à-faire reste désespérément plate. Pour les parties prenantes extérieures ou la direction, l’impression produite est trompeuse : l’équipe semble n’avoir rien livré et stagner.

Le Burnup Chart résout ce problème de manière magistrale. En séparant la courbe du travail accompli de la ligne de périmètre global, il rend le Scope Creep (le glissement ou l’augmentation involontaire du périmètre) immédiatement visible :

• Si le périmètre augmente, la ligne supérieure de portée totale monte d’un palier.
• La ligne inférieure de travail complété continue sa progression vers le haut, prouvant de façon indiscutable que l’équipe de développement maintient son rythme de livraison.

Cette distinction est fondamentale pour instaurer un dialogue sain et factuel entre l’équipe, le Product Owner et les parties prenantes en cas de dérive des délais.

Comment lire et interpréter un Burnup Chart : exemples concrets et chiffrés

Exemple 1 : Suivi au niveau d’un Sprint

Imaginons une équipe engagée dans un Sprint de 10 jours ouvrés :

• Jour 1 : Périmètre engagé = 30 Story Points (ligne de portée à 30 SP). Travail complété = 0 SP.
• Jour 5 : L’équipe a finalisé 12 SP. Cependant, suite à une découverte technique critique lors du Daily Scrum, le Product Owner ajoute 6 SP de travaux indispensables. La ligne de portée monte immédiatement à 36 SP, tandis que la ligne de réalisé pointe à 12 SP.
• Jour 10 : L’équipe termine le Sprint en atteignant 30 SP complétés.

Analyse : Sur un Burndown, à J5, le reste-à-faire indiquait 24 SP (36 – 12), donnant le sentiment négatif que l’équipe n’avait avancé que de 6 SP par rapport au départ. Sur le Burnup Chart, il apparaît clairement que l’équipe a livré 30 SP sur les 10 jours et que les 6 SP restants non livrés découlent directement de l’extension de périmètre survenue à mi-Sprint.

Exemple 2 : Extrapolation et prévision au niveau d’une Release Produit

Considérons maintenant une release majeure planifiée sur plusieurs Sprints :

• Périmètre initial : 120 Story Points planifiés sur 6 Sprints.
• Sprint 1 : 20 SP complétés (Périmètre : 120 SP).
• Sprint 2 : 22 SP complétés, soit un cumul de 42 SP (Périmètre : 120 SP). La vélocité moyenne de l’équipe s’établit à 21 SP par Sprint.
• Sprint 3 : L’équipe complète 21 SP supplémentaires (cumul = 63 SP). Lors de la Sprint Review, les parties prenantes demandent l’ajout d’un nouveau module estimé à 30 SP. La ligne de portée totale bondit de 120 SP à 150 SP.

Comment estimer la date de livraison par extrapolation mathématique et visuelle ?

1. Calcul du reste à faire : Périmètre actuel (150 SP) – Travail complété (63 SP) = 87 SP restants.
2. Nombre de Sprints nécessaires : 87 SP / 21 SP (vélocité moyenne) = 4,14 Sprints supplémentaires.
3. Projection totale : 3 Sprints déjà réalisés + 5 Sprints restants (arrondi supérieur) = 8 Sprints au total.

Graphiquement, il suffit de prolonger la droite de tendance du travail complété (pente représentant la vélocité de 21 SP/Sprint) jusqu’à ce qu’elle croise la ligne horizontale ajustée du périmètre (150 SP). Le point d’intersection se projette sur l’axe des X au niveau du Sprint 8. Le Product Owner peut ainsi présenter immédiatement deux options aux décideurs : accepter une livraison au Sprint 8 ou supprimer 30 SP de fonctionnalités secondaires pour maintenir l’échéance initiale du Sprint 6.

Les pièges et erreurs fréquentes à éviter

Même si le Burnup Chart est un outil de pilotage très performant, certaines erreurs d’utilisation peuvent altérer sa valeur empirique :

• Ne pas mettre à jour la ligne de périmètre : Si des User Stories sont ajoutées ou retirées du Backlog sans ajuster la ligne supérieure du Burnup, le graphique perd son avantage principal et devient faux.
• Confondre Burnup et Burndown Chart : Présenter un Burnup à un comité de direction sans expliquer que la courbe doit monter (et non descendre) crée souvent des confusions regrettables.
• Compter du travail « presque fini » : Créditer des Story Points pour des tâches partiellement codées mais non testées viole le principe fondamental du produit utilisable. Seul le travail conforme à la Definition of Done fait monter la courbe du réalisé.
• Utiliser le Burnup comme outil de pression coercitif : Chercher à forcer artificiellement la pente de la courbe de réalisé nuit à la qualité du code et favorise la dette technique. Le Burnup est un instrument d’observation empirique et d’adaptation, dans l’esprit des enseignements de Mike Cohn sur la planification agile.

Les outils pour générer automatiquement vos Burnup Charts

Aujourd’hui, il n’est plus nécessaire de tracer ces graphiques à la main sur un tableau blanc ou dans un tableur, même si la pratique physique conserve des vertus pédagogiques. Les principaux logiciels de gestion de projet intègrent nativement des rapports Burnup complets :

• Jira (d’Atlassian) : Propose un rapport Burnup très élaboré pour les tableaux Scrum, calculé automatiquement en Story Points, en nombre de tickets ou en heures, avec distinction claire du périmètre et des livraisons.
• Azure DevOps (de Microsoft) : Offre des widgets Burnup configurables sur les tableaux de bord d’Azure Boards, permettant un suivi précis au niveau du Sprint, du Feature ou de l’Epic.
• D’autres outils collaboratifs comme Trello (via des Power-Ups), Miro ou des intégrations dans Confluence permettent également de matérialiser ces graphiques pour vos équipes.

Que vous travailliez en Scrum, en Kanban, en Extreme Programming, en Lean management ou dans un cadre à grande échelle comme SAFe, l’adoption du Burnup Chart renforce la lisibilité de vos projets et facilite la prise de décision partagée avec vos parties prenantes.

Pour aller plus loin

Pour approfondir vos connaissances sur l’estimation, le suivi d’avancement et la gestion empirique des projets agiles, nous vous recommandons les ouvrages de référence suivants :

• Scrum : un outil convivial pour une agilité radicale (6e édition) par Claude Aubry (Éditions Dunod) — Un guide francophone incontournable pour structurer vos Sprints et piloter l’avancement avec sérénité.
• Agile Estimating and Planning par Mike Cohn (Prentice Hall) — L’ouvrage fondamental sur l’art d’estimer en Story Points, de mesurer la vélocité et d’extrapoler les dates de livraison.
• Scrum: The Art of Doing Twice the Work in Half the Time par Jeff Sutherland (Crown Business) — Le livre du co-créateur de Scrum pour comprendre l’esprit empirique derrière la mesure de la valeur et de l’effort.

Chaque organisme certifiant, qu’il s’agisse de Scrum.org ou de la Scrum Alliance, insiste sur l’importance de ces métriques visuelles pour encourager l’auto-organisation et la transparence au sein des équipes.

Et vous, utilisez-vous plutôt le Burnup Chart ou le Burndown Chart dans vos équipes, et comment gérez-vous la visibilité du Scope Creep auprès de vos parties prenantes ? Partagez vos retours d’expérience et vos astuces dans les commentaires ci-dessous !

Photo : ThisIsEngineering sur Pexels.

Pour aller plus loin

Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.

Autres ressources sur l’agilité

• Les cérémonies Scrum : le guide complet pour rythmer vos Sprints
• Glossaire Scrum : tous les termes de l’agilité expliqués
• La Méthode Scrum
• Le scrum master : un rôle déterminant de l’agilité
• Les Méthodes Agiles

Sources

• The Scrum Guide Official – Jeff Sutherland & Ken Schwaber
• Atlassian Support – View and understand the Burnup chart or report in Jira
• Microsoft Learn – Azure DevOps Dashboards & Widgets (Burnup & Burndown)
• Miro Guide – What is a burnup chart and how to use it?