Dans la gestion de projet Agile, la visibilité est le nerf de la guerre. Si le Burndown chart est souvent le premier outil utilisé pour suivre la progression au sein d’un sprint, il montre ses limites dès que la complexité augmente. Le burn up chart apporte une réponse plus stratégique : il permet de visualiser non seulement le travail accompli, mais aussi l’évolution de l’envergure globale du projet.
Qu’est-ce qu’un burn up chart et pourquoi l’utiliser ?
Le burn up chart est un outil de management visuel qui suit l’évolution du travail réalisé par rapport à la quantité totale prévue pour un projet ou une release. Contrairement aux graphiques qui se limitent au travail restant, le burn up décompose l’information en deux courbes distinctes : le travail total, ou périmètre, et le travail terminé.
La structure du graphique
Pour lire un burn up chart, il faut observer deux axes. L’axe horizontal (X) représente le temps, découpé en jours, semaines ou itérations. L’axe vertical (Y) mesure la quantité de travail, exprimée en story points, en nombre de tickets ou en jours-homme.
Le graphique affiche deux lignes principales :
- La ligne de périmètre : Elle indique la somme totale de travail nécessaire. Si de nouvelles fonctionnalités sont ajoutées, cette ligne monte.
- La ligne de réalisation : Elle montre le cumul des tâches terminées. Elle progresse uniquement vers le haut ou reste stable.
Un outil de transparence pour les parties prenantes
Le burn up chart communique avec clarté auprès des clients ou de la direction. Là où un simple pourcentage d’avancement peut être trompeur, ce graphique montre la réalité brute. Si un projet prend du retard, il permet de distinguer immédiatement si la cause est une baisse de productivité de l’équipe ou un scope creep, c’est-à-dire un gonflement du périmètre initial.
Les bénéfices du burn up chart face au burndown
Bien que souvent confondus, l’utilité du burn up et du burndown diffère selon le niveau de lecture. Le burndown est adapté à l’auto-gestion quotidienne pendant un sprint, tandis que le burn up est l’outil de prédilection pour le pilotage à moyen et long terme.
Visualiser la dérive du périmètre
Dans un burndown chart, l’ajout de tâches en cours de sprint fait remonter la courbe de travail restant, ce qui peut décourager l’équipe. Le burn up chart résout ce problème : si le périmètre augmente, la ligne supérieure monte, mais la ligne de réalisation continue de progresser de son côté. On voit alors clairement que l’équipe travaille, même si la cible s’éloigne.
Cette distinction est essentielle pour la santé mentale des développeurs. La gestion de projet s’apparente à la culture d’un jardin. Chaque fonctionnalité est une graine. Si le Product Owner continue d’ajouter des variétés sans tenir compte de la surface disponible, le terrain sature. Le burn up chart agit comme un plan cadastral évolutif, montrant ce qui a poussé et l’expansion constante des plates-bandes, permettant de décider rationnellement s’il faut arrêter de semer ou agrandir l’équipe.
Prédire la date de fin avec réalisme
En observant la pente de la ligne de réalisation, qui correspond à la vélocité moyenne, et la tendance de la ligne de périmètre, on peut projeter le point de rencontre des deux courbes. Ce point d’intersection donne une estimation réaliste de la date de livraison. C’est un levier de négociation : si le client souhaite une date de sortie plus proche, le graphique montre visuellement qu’il doit soit réduire le périmètre, soit augmenter la capacité de l’équipe.
Comment construire et alimenter votre graphique étape par étape ?
La mise en place d’un burn up chart ne nécessite pas d’outils complexes. Comprendre la mécanique manuelle permet de mieux interpréter les données, même si des logiciels comme Jira ou Azure DevOps les génèrent automatiquement.
Étape 1 : Définir l’unité de mesure et le backlog
L’équipe doit s’accorder sur une unité de mesure commune. Les story points sont recommandés car ils reflètent l’effort et la complexité plutôt que le temps pur. Additionnez la valeur de tous les éléments du backlog de la release pour obtenir votre point de départ sur l’axe vertical.
Étape 2 : Tracer la ligne de périmètre
Au jour zéro, placez un point représentant le total des points du backlog. À chaque fin d’itération, vérifiez si des éléments ont été ajoutés ou supprimés. Si le Product Owner ajoute une fonctionnalité de 13 points, votre ligne de périmètre grimpe de 13 unités. Cette mise à jour régulière reflète l’agilité réelle du projet.
Étape 3 : Reporter le travail terminé
À la fin de chaque période, calculez la somme des points des user stories qui répondent strictement à la « Definition of Done ». Reportez ce cumul sur le graphique. La progression doit idéalement suivre une pente régulière. Des plateaux horizontaux prolongés indiquent souvent des bloqueurs techniques ou des processus de validation trop longs.
| Sprint n° | Périmètre total (Points) | Travail cumulé réalisé | Commentaire |
|---|---|---|---|
| 1 | 100 | 15 | Démarrage nominal |
| 2 | 120 | 35 | Ajout de fonctionnalités (+20 pts) |
| 3 | 120 | 60 | Bonne vélocité maintenue |
Interpréter les anomalies : ce que le graphique révèle
Un burn up chart est un diagnostic de santé du projet. Savoir lire entre les lignes permet d’anticiper les crises.
La ligne de périmètre en escalier
Si la ligne supérieure monte à chaque itération, le périmètre n’est jamais stabilisé. Dans ce cas, la ligne de réalisation ne rattrapera jamais la cible. C’est le signal qu’il faut organiser une réunion de priorisation pour geler certaines fonctionnalités et se concentrer sur le Produit Minimum Viable (MVP).
L’écart qui se creuse
Si la distance verticale entre les deux lignes augmente, le risque projet explose. Cela indique souvent que l’équipe découvre une complexité technique imprévue qui gonfle les estimations, ou que la vitesse de production ralentit. Il est alors nécessaire d’analyser la vélocité : l’équipe est-elle surchargée ou une dette technique freine-t-elle le développement ?
Le plateau de réalisation
Une ligne de réalisation qui reste plate sur plusieurs sprints est un signal d’alarme. Cela peut signifier que les tâches sont trop volumineuses pour être terminées dans le sprint, ou qu’un goulot d’étranglement extérieur, comme une validation juridique ou une dépendance technique, bloque la chaîne de production. Le burn up chart rend ce blocage visible, forçant une résolution collective.
Bonnes pratiques pour un usage efficace
Pour que le burn up chart devienne un allié, quelques règles s’imposent. La mise à jour doit être fréquente et honnête. Un graphique non actualisé à chaque fin de sprint perd toute sa valeur prédictive.
Évitez de l’utiliser comme un outil de contrôle de la performance individuelle. Le burn up mesure la capacité d’une équipe entière à livrer de la valeur. Si la pente est faible, la question n’est pas de savoir qui a travaillé, mais ce qui empêche l’équipe d’avancer.
Enfin, annotez votre graphique. Un commentaire sur un pic de périmètre ou une stagnation, comme « changement de stratégie marketing » ou « dépendance technique », permet de garder une trace historique et facilite les rétrospectives. En transformant des données froides en une narration visuelle, le burn up chart garantit une collaboration saine et une livraison réussie.
Articles qui pourraient vous intéresser :
Conseil marketing : 3 leviers pour transformer votre vision en résultats concrets
Défi économie : 1 378 euros mis de côté en 52 semaines sans effort
Choisir sa méthode de gestion de projet : 4 critères pour éviter l’échec opérationnel
Formation Scala : maîtrisez la programmation fonctionnelle et boostez vos projets JVM