Quelle est la différence entre Burn Up et Burn Down ?

Le Burn Down descend vers 0 (travail restant). Le Burn Up monte vers le scope (travail terminé) et affiche en plus une ligne Scope qui rend visible tout changement de périmètre.

Pourquoi le Burn Up montre-t-il le scope ?

Pour rendre visibles les ajouts et retraits d'items, ce que le Burn Down masque totalement. C'est le pilier de transparence de l'empirisme.

Le Scrum Guide parle-t-il du Burn Up ?

Non. Depuis 2011, le Scrum Guide ne cite aucun outil de suivi (Burn Down, Burn Up, CFD). Ce sont des pratiques externes.

Le Burn Up est-il utilisé pendant une Release ?

Oui, c'est même son usage privilégié : projection de la date de fin, gestion du scope creep, communication avec les stakeholders.

Le Burn Up remplace-t-il le Sprint Backlog ?

Non. Le Sprint Backlog liste ce qu'il faut faire et comment. Le Burn Up visualise l'avancement.

Quelle unité utiliser sur l'axe Y ?

De préférence les Story Points, sinon le nombre d'items Done. Éviter les heures — moins fiables et moins alignées avec l'agilité.

Peut-on faire un Burn Up dans Excel ?

Oui. Un tableau avec colonnes Jour / Sprint, SP terminés, SP au scope, plus un graphique en courbes suffit largement.

Comment créer un Burn Up dans Jira ?

Reports → Sprint Burnup pour un Sprint. Advanced Roadmaps pour une Release ou une initiative.

Le Burn Up est-il utile au Product Owner ?

Oui, plus qu'un Burn Down : il matérialise l'impact des décisions de scope et facilite la communication avec les stakeholders.

Que faire si la ligne Done stagne pendant plusieurs jours ?

Enquêter en Daily : blocage, dépendance externe, story trop grosse à découper. Le Scrum Master aide à lever l'obstacle.

Que faire si la ligne Scope explose en cours de Sprint ?

Renégocier le Sprint Goal avec le Product Owner ou reporter les ajouts au prochain Sprint. Le Sprint reste protégé.

Un Burn Up peut-il descendre ?

Oui — la ligne Done ne descend jamais, mais la ligne Scope peut baisser lors d'un descoping (items retirés du backlog).

Le Burn Up est-il un KPI ?

Non. C'est un outil d'inspection empirique pour l'équipe, jamais un indicateur de performance individuelle.

Peut-on comparer les Burn Up de deux équipes ?

Non. Les Story Points sont relatifs à chaque équipe : toute comparaison inter-équipes n'a pas de sens.

Le Burn Up doit-il apparaître en Sprint Review ?

Souvent oui, comme support factuel du Sprint écoulé et de la valeur livrée.

Peut-on tracer un Burn Up sur tout le Product Backlog ?

Techniquement oui, mais le backlog évolue en continu : le graphique perd rapidement en lisibilité. Préférez un Burn Up par Product Goal.

Le Burn Up est-il compatible avec Kanban ?

Il existe des variantes, mais Kanban privilégie le diagramme de flux cumulatif (CFD), le throughput et le lead time.

Quelle différence entre Burn Up et Velocity ?

La Velocity est un indicateur multi-Sprints (SP moyens livrés). Le Burn Up est un graphique de suivi, souvent alimenté par la Velocity pour ses projections.

Le Burn Up est-il utilisé en SAFe ?

Oui, notamment sous forme de PI Burn Up (Program Increment) pour suivre l'avancement d'un programme sur plusieurs Sprints.

Le Burn Up est-il apparu dans le Scrum Guide un jour ?

Non. C'est une pratique issue de la communauté agile, notamment popularisée par Mike Cohn.

Peut-on prédire la date de fin avec un Burn Up ?

Oui, en prolongeant la ligne Done à partir de la vélocité moyenne. On obtient une fourchette de dates de fin fiable.

Que faire si les deux lignes ne convergent jamais ?

Soit la vélocité est trop faible pour le scope engagé, soit le scope augmente plus vite que la production. Un arbitrage PO est nécessaire.

Peut-on utiliser un Burn Up sans Story Points ?

Oui, en comptant les items Done (nombre de tickets). C'est moins précis mais parfaitement utilisable.

Le Burn Up est-il utile en cascade (Waterfall) ?

Peu. Sans travail incrémental et sans Definition of Done, la ligne Done reflète mal la valeur réellement livrée.

Peut-on utiliser Burn Up et Burn Down en même temps ?

Oui, ils sont complémentaires. Beaucoup d'équipes affichent le Burn Down du Sprint en cours et le Burn Up de la Release en parallèle.

Comment interpréter une courbe Done en escalier ?

Les stories sont probablement trop grosses. Découper à moins de 8 SP améliore la régularité.

Le Burn Up remplace-t-il la Retrospective ?

Non. Il peut servir de support factuel en Retrospective, mais ne remplace en rien l'analyse et le plan d'action de l'équipe.

Où puis-je m'entraîner sur des questions PSM I liées au Burn Up ?

Sur PasseTonScrum : plus de 320 questions PSM I originales avec corrections détaillées, incluant les artefacts complémentaires comme le Burn Up et le Burn Down.

Burn Up Chart : définition, fonctionnement et exemples Scrum

Q: Qu'est-ce qu'un Burn Up Chart ?

Un graphique de suivi qui trace deux lignes : le travail terminé (Done) et le périmètre total (Scope). Il monte au fil du temps.

Q: Le Burn Up est-il obligatoire en Scrum ?

Non. Le Scrum Guide 2020 ne mentionne aucun graphique. Le Burn Up est une pratique complémentaire, à choisir librement.

Q: Qui met à jour le Burn Up ?

Les Developers, généralement au moment du Daily Scrum, à partir du Sprint Backlog.

1. Résumé en 30 secondes

2. Qu'est-ce qu'un Burn Up Chart ?

Le Burn Up Chart (ou diagramme Burn Up) est un graphique de suivi qui visualise le travail terminé au fil du temps, tout en affichant en parallèle le périmètre total à réaliser. Deux lignes coexistent :

La ligne Done — les Story Points (ou items) terminés selon la Definition of Done.
La ligne Scope — le périmètre total de ce qui doit être fait.

Il est utilisé aussi bien pour un Sprint que pour une release ou un Product Goal. Il est le complément naturel du Burn Down Chart, dont il corrige la principale faiblesse : l'invisibilité des changements de périmètre.

Historiquement inspiré des pratiques XP, popularisé par Mike Cohn au début des années 2000, le Burn Up est aujourd'hui le graphique privilégié par les équipes travaillant sur des releases longues ou en découverte produit.

3. Visualisation animée

Voici à quoi ressemble un Burn Up de Sprint sain : la ligne Done grimpe régulièrement vers la ligne Scope, qui reste stable.

Burn Up d'un Sprint sain (Done monte vers Scope)

Travail terminéPérimètre (scope)

4. Comment lire un Burn Up Chart

Axe X — Temps

Représente la durée du Sprint (en jours) ou de la Release (en Sprints). Chaque tick = un point de mesure. Mise à jour recommandée : au Daily Scrum.

Axe Y — Story Points

Représente les Story Points (ou items). Le total correspond au scope maximum. Éviter les heures — moins fiables et moins alignées avec la pratique agile.

Ligne Done (courbe principale)

Chaque item terminé selon la Definition of Done fait monter la ligne. C'est la mesure factuelle de la valeur livrée.

Ligne Scope (courbe secondaire)

Trace l'évolution du périmètre. Elle monte si le Product Owner ajoute des items, elle descend en cas de descoping. C'est l'atout du Burn Up.

5. Pourquoi utiliser un Burn Up Chart ?

Le Burn Up apporte quatre bénéfices que le Burn Down n'offre pas :

Visualisation double — travail terminé et scope, sur un seul graphique.
Transparence sur le scope — chaque ajout/retrait d'items est immédiatement visible, matérialisant l'un des trois piliers de l'empirisme.
Communication facilitée — les stakeholders comprennent visuellement l'impact d'un changement.
Plus lisible en périmètre mouvant — un Burn Down devient trompeur lorsque le scope change ; le Burn Up reste clair.

6. Burn Up vs Burn Down : le grand comparatif

Burn Up vs Burn Down
Critère	Burn Up Chart	Burn Down Chart
Ce qui est tracé	Travail terminé (Done) + périmètre (Scope)	Travail restant
Direction de la courbe	Monte vers Scope	Descend vers 0
Nombre de lignes	2 (Done + Scope)	2 (Idéale + Réelle)
Gestion du scope	Rendue explicite par la ligne Scope	Invisible — le scope creep est masqué
Lecture rapide	Convergence Done ↔ Scope = fin	Ligne réelle qui touche 0 = fin
Usage Sprint	Utile, surtout si le scope peut bouger	Historiquement le plus utilisé
Usage Release	★ Recommandé — projection facile	Moins pertinent (scope évolutif)
Usage Produit	★ Idéal pour un Product Goal	Peu adapté (backlog vivant)
Communication stakeholders	★ Excellente — visuel intuitif	Bonne, sauf en cas d'ajout de scope
Question PSM I	Testé sur la notion de non-obligation et de rôle des Developers	Idem

7. Réagir aux changements de scope

Voici la vraie force du Burn Up : lorsque le Product Owner ajoute des items au Product Backlog, la ligne Scope monte visiblement. Le Done continue de grimper — mais on voit désormais l'écart à combler.

Burn Up avec ajout de scope — le graphique reste lisible

Travail terminéPérimètre (scope)

Sur un Burn Down classique, cet ajout serait invisible : la ligne réelle continuerait de descendre en cachant l'augmentation du travail à faire. Le Burn Up rend la réalité incontournable — un outil précieux pour préserver la transparence.

8. Burn Up pendant un Sprint

Sur un Sprint, la ligne Scope est en principe stable après le Sprint Planning : le Sprint Backlog a été construit et engagé par les Developers.

Simulateur de Burn Up — modifiez les paramètres

Story Points prévusDurée du Sprint (jours)Scénario

Scénario : Sprint sain

Travail terminéPérimètre (scope)

Bonnes pratiques Sprint

Mise à jour quotidienne, avant le Daily Scrum.
Une story ne compte que si elle respecte la Definition of Done.
Toute augmentation de scope doit tracer une marche sur la ligne Scope.
Afficher le graphique dans un endroit visible (mur physique, écran équipe).

9. Burn Up sur une Release

Le Burn Up est l'outil roi du Release Planning. L'axe X est en Sprints, la ligne Done monte par paliers (un palier = un Sprint), et la ligne Scope évolue au fur et à mesure que le backlog est raffiné.

Release Burn Up sur 8 Sprints

Travail terminéPérimètre (scope)

À partir de la vélocité moyenne, il devient possible de projeter la date probable d'atteinte de la ligne Scope — un argument objectif face aux stakeholders. Cette projection est bien plus fiable qu'un jalon Waterfall figé.

10. Burn Up produit (Product Goal)

À l'échelle produit, le Burn Up permet de suivre l'avancement vers un Product Goal. La ligne Scope correspond à l'ensemble des items alignés avec ce Product Goal — elle évolue à chaque refinement.

Ce Burn Up devient un composant naturel de la roadmap produit et alimente les discussions de vision long terme. Il n'a pas vocation à devenir un engagement : c'est une prévision empirique.

11. 8 exemples détaillés par secteur

Ces huit cas concrets illustrent comment le Burn Up s'utilise dans des environnements variés. Chaque exemple précise l'objectif, le scope initial, la lecture du graphique et l'interprétation opérationnelle.

Développement logiciel (SaaS B2B)

Objectif : Livrer la V1 du module de facturation avant la fin du trimestre.

Scope : 80 SP répartis sur 4 Sprints. Ajout de 15 SP au Sprint 3 pour un besoin RGPD imposé.

Lecture : La courbe Done monte régulièrement (~20 SP par Sprint). La ligne Scope reste plate puis remonte à 95 SP au Sprint 3.

Interprétation : Le Burn Up montre visuellement l'impact d'un changement réglementaire. Le PO reporte deux stories non critiques au Sprint 5.

Application mobile (e-santé)

Objectif : Publier la V1 iOS/Android sur les stores.

Scope : 120 SP sur 6 Sprints. Scope stable — priorisation forte.

Lecture : Ligne Done qui converge vers 120 au Sprint 6. Ligne Scope constante.

Interprétation : Le Burn Up produit rassure le sponsor : la date de lancement est atteignable si la vélocité tient (~20 SP/Sprint).

Migration Cloud (multi-comptes AWS)

Objectif : Migrer 40 services vers EKS avant la coupure du datacenter.

Scope : 200 SP répartis sur 10 Sprints, mais découverte de 45 SP supplémentaires liés au réseau.

Lecture : La ligne Scope monte 3 fois (S3, S5, S7). La ligne Done suit avec un léger retard.

Interprétation : Le Burn Up justifie la demande de 2 Sprints supplémentaires auprès du COMEX — chiffres à l'appui.

Infrastructure (SRE, refonte observabilité)

Objectif : Instrumenter 100 % des services avec OpenTelemetry.

Scope : 150 SP sur 8 Sprints. Scope diminué au Sprint 4 (services obsolètes retirés).

Lecture : Ligne Done stable, ligne Scope qui descend de 150 à 120 au Sprint 4.

Interprétation : Le Burn Up rend visible le gain de temps grâce au descoping — un argument fort en Sprint Review.

Banque (application client)

Objectif : Livrer la V2 de la messagerie sécurisée.

Scope : 60 SP sur 3 Sprints. Contrainte compliance imposant un ajout de 12 SP au Sprint 2.

Lecture : Done monte de 20 SP par Sprint. Scope à 60 puis 72 au Sprint 2.

Interprétation : Le Sprint 3 termine à 60/72 : le PO négocie le report des 12 SP compliance en V2.1.

Assurance (souscription en ligne)

Objectif : Automatiser 90 % du parcours de souscription auto.

Scope : 180 SP sur 9 Sprints.

Lecture : Ligne Done linéaire, ligne Scope constante.

Interprétation : Le Burn Up sert de tableau de bord au sponsor : projection fiable de la date de mise en production.

Santé (télémédecine)

Objectif : Ouvrir la téléconsultation à 3 nouvelles spécialités.

Scope : 90 SP sur 5 Sprints. Un événement réglementaire ajoute 20 SP au Sprint 3.

Lecture : Done à 55 en fin de Sprint 3, Scope à 110.

Interprétation : Le PO priorise deux spécialités sur les trois pour tenir la date. Le Burn Up rend l'arbitrage lisible.

E-commerce (marketplace)

Objectif : Lancer le programme de fidélité multi-marques.

Scope : 140 SP sur 7 Sprints. Scope stable.

Lecture : Done grimpe régulièrement, la courbe croise la Scope au Sprint 7.

Interprétation : Release réussie sans surprise, grâce à un refinement continu et un Burn Up mis à jour à chaque Sprint.

12. 8 erreurs fréquentes

Les erreurs sur le Burn Up sont fréquentes et souvent identiques d'une équipe à l'autre. Les identifier, c'est déjà les éviter.

1. Confondre Burn Up et Burn Down

À éviter : Interpréter la ligne qui monte comme un signal d'alerte, ou attendre qu'elle descende à zéro.

Bonne pratique : Le Burn Up monte vers le scope : c'est la logique inverse du Burn Down. La convergence Done ↔ Scope signale la fin.

2. Ne pas mettre à jour quotidiennement

À éviter : Actualiser le graphique en fin de Sprint pour la Review — trop tard pour agir.

Bonne pratique : Mise à jour à chaque Daily Scrum, par les Developers, à partir du travail Done selon la Definition of Done.

3. Ignorer les changements de scope

À éviter : Laisser la ligne Scope constante alors que le PO a ajouté ou retiré des items.

Bonne pratique : Chaque évolution du scope doit se refléter immédiatement sur la courbe supérieure. C'est LA valeur du Burn Up.

4. Utiliser le Burn Up pour évaluer les personnes

À éviter : Reprocher à un développeur la lenteur de la courbe Done.

Bonne pratique : Le Burn Up est un outil d'équipe, jamais un KPI individuel. La responsabilité du Sprint est collective.

5. Confondre Product Backlog et scope du Burn Up

À éviter : Tracer un Burn Up sur l'ensemble du Product Backlog, qui évolue en continu — le graphique devient illisible.

Bonne pratique : Le Burn Up cible un périmètre défini : un Sprint, une Release, un Product Goal. Pas un backlog vivant.

6. Mélanger unités (SP + heures)

À éviter : Tracer un axe Y en heures alors que le backlog est estimé en Story Points.

Bonne pratique : Choisir une unité et s'y tenir : Story Points (recommandé) ou nombre d'items. Jamais deux à la fois.

7. Interpréter les micro-écarts

À éviter : Paniquer parce que la courbe Done est en retard de 2 SP au J3.

Bonne pratique : Analyser les tendances sur plusieurs Daily. Un Burn Up doit être lu à horizon Sprint, pas à horizon jour.

8. Considérer le Burn Up comme obligatoire

À éviter : Refuser de commencer un Sprint sans Burn Up.

Bonne pratique : Le Scrum Guide 2020 ne mentionne aucun graphique. Le Burn Up est une pratique complémentaire, à choisir librement.

13. Burn Up dans Jira

Jira propose un rapport Burn Up natif : Reports → Sprint Burnup pour un Sprint, ou Advanced Roadmaps pour une release / initiative. Jira agrège automatiquement :

La courbe Done à partir des tickets passés au statut Done.
La courbe Scope à partir des tickets présents dans le Sprint / Epic / Release.

Cas d'usage

Sprint Burnup pour une équipe unique.
Release Burnup à travers Advanced Roadmaps pour un programme multi-équipes.

Limites

Le calcul dépend fortement du champ Story Points renseigné correctement.
Les ajouts/retraits d'items en cours de Sprint ne sont pas toujours horodatés fidèlement.
Advanced Roadmaps est payant sur les plans Standard et gratuit uniquement en Premium.

14. Burn Up dans Excel

Excel (ou Google Sheets) est une excellente première approche pour comprendre la mécanique du Burn Up avant d'automatiser via Jira, Azure DevOps ou Linear.

Quand Excel suffit

Petite équipe (moins de 8 personnes) sans budget outillage.
Formation interne, atelier de découverte.
Sprint pilote de 2-3 semaines pour tester l'usage.

Quand basculer vers un outil Agile

Plusieurs équipes travaillent sur le même produit.
Le backlog dépasse 100 items — la maintenance devient coûteuse.
Besoin d'un audit trail (qui a modifié quoi et quand).

15. 6 questions PSM I corrigées

Le Burn Up n'apparaît pas dans le Scrum Guide 2020, mais des questions PSM I portent régulièrement sur les artefacts complémentaires et leur rôle. Voici les formulations les plus courantes.

Question 1. Que représente l'axe vertical d'un Burn Up Chart ?

Le travail restant à réaliser
Le travail terminé (Done)
Le nombre de développeurs disponibles
La vélocité cumulée depuis le début du produit

Bonne réponse : B. Le travail terminé (Done)

Pourquoi : L'axe Y d'un Burn Up mesure le travail Done (généralement en Story Points). Il monte au fil du temps, contrairement au Burn Down qui descend.