1. Qu'est-ce qu'un Burn Down Chart ?
Le Burn Down Chart (ou graphique de consommation) est un graphique qui visualise le travail restant à réaliser au fil du temps sur un Sprint. C'est l'un des outils les plus utilisés en Scrum pour rendre le travail restant transparent, un principe fondamental de l'empirisme.
Concrètement, un Burn Down présente deux courbes :
- La ligne idéale — trajectoire linéaire allant du volume total de Story Points au premier jour, jusqu'à 0 au dernier jour.
- La ligne réelle — travail effectivement restant, mise à jour chaque jour lors du Daily Scrum.
Attention : depuis la version 2011 du Scrum Guide, le Burn Down Chart n'est plus un artefact officiel de Scrum. Il reste néanmoins une pratique très largement adoptée car elle rend visible ce que Scrum demande : le travail restant pour atteindre le Sprint Goal.
2. À quoi sert un Burn Down Chart ?
Un Burn Down remplit cinq fonctions concrètes :
- Rendre le travail restant transparent — pilier n°1 de l'empirisme Scrum (transparence, inspection, adaptation).
- Détecter les retards tôt — quand la courbe réelle diverge, l'équipe peut réagir avant qu'il soit trop tard.
- Repérer un blocage — une courbe plate 2-3 jours de suite = obstacle à lever d'urgence.
- Renforcer l'auto-organisation — l'équipe voit l'avancement et ajuste elle-même le plan.
- Alimenter la Sprint Retrospective — le graphique final devient un support factuel pour l'inspection.
3. Comment lire un Burn Down Chart ?
Lire un Burn Down consiste à comparer, jour après jour, la ligne réelle à la ligne idéale. Trois cas majeurs :
- Ligne réelle au-dessus — l'équipe est en retard sur la trajectoire.
- Ligne réelle en dessous — l'équipe est en avance (ou sous-engagée initialement).
- Ligne réelle plate — rien n'a été « Done » selon la Definition of Done ces derniers jours. Signal fort.
Attention à ne pas sur-interpréter chaque petite variation. Un Burn Down se lit sur la durée du Sprint, pas au jour près.
4. Les éléments du graphique
| Élément | Rôle | Bonne pratique |
|---|---|---|
| Axe X (horizontal) | Représente le temps (jours du Sprint) | Toujours en jours ouvrés |
| Axe Y (vertical) | Représente le travail restant | En Story Points ou items — jamais en heures |
| Ligne idéale | Trajectoire théorique linéaire | Ligne pointillée grise |
| Ligne réelle | Travail restant effectivement | Mise à jour chaque Daily Scrum |
| Point de départ | Somme des SP du Sprint Backlog | Fixé après la Sprint Planning |
| Point d'arrivée | 0 SP restants | À la fin du dernier jour du Sprint |
5. Comment construire un Burn Down Chart ?
- Additionner les Story Points du Sprint Backlog après la Sprint Planning.
- Placer les axes : X = jours (J0 à Jn), Y = SP restants (0 à total).
- Tracer la ligne idéale reliant (J0, total) à (Jn, 0).
- Chaque jour (Daily Scrum), retirer les SP des items 100 % Done.
- Reporter les nouveaux points sur la ligne réelle.
- Analyser en équipe : retard, avance, plateau, scope creep.
Laissez une cellule vide pour utiliser la ligne idéale à ce jour.
6. Exemple complet d'un Sprint
Prenons une équipe de 5 développeurs avec un Sprint Backlog de 40 SP sur 10 jours ouvrés.
| Jour | SP idéaux restants | SP réels restants | Interprétation |
|---|---|---|---|
| J0 | 40 | 40 | Point de départ |
| J1 | 36 | 40 | Pas encore de Done — normal |
| J2 | 32 | 38 | Première story Done |
| J3 | 28 | 34 | Rythme correct |
| J4 | 24 | 30 | Léger retard |
| J5 | 20 | 28 | Retard installé |
| J6 | 16 | 20 | Rattrapage |
| J7 | 12 | 15 | Bon rythme |
| J8 | 8 | 12 | Toujours en léger retard |
| J9 | 4 | 5 | Sprint quasi tenu |
| J10 | 0 | 0 | Sprint Goal atteint |
Ce Sprint illustre un pattern courant : un démarrage plus lent que prévu (J1-J5), puis un rattrapage à mi-parcours. Bien lu en Daily, ce signal permet à l'équipe de réajuster son plan sans attendre la Sprint Review.
7. Comment interpréter les écarts ?
| Pattern | Cause probable | Action recommandée |
|---|---|---|
| Ligne réelle constamment au-dessus | Sur-engagement en Sprint Planning | Réduire le Sprint Backlog au prochain Sprint |
| Ligne plate 2-3 jours | Blocage (dépendance, technique) | Scrum Master lève l'obstacle |
| Chute brutale en fin de Sprint | Culture du « tout à la fin » | Découper mieux les stories |
| Ligne réelle très en dessous | Sous-engagement | Ajouter du scope si Sprint Goal atteint |
| Remontée de la ligne | Ajout de scope en cours | Renégocier Sprint Goal / refuser |
| Progression en marches d'escalier | Stories trop grosses | Découper à < 8 SP |
8. Les erreurs fréquentes
Les 17 pièges qui reviennent le plus souvent dans les équipes Scrum :
Pourquoi : Le Burn Down n'évalue jamais un développeur. Il inspecte le travail de l'équipe.
Bonne pratique : Réserver la lecture à la Daily et à la Retrospective.
Pourquoi : Un Burn Down stale devient inutile pour l'auto-inspection.
Bonne pratique : Mettre à jour à chaque Daily Scrum, avant de démarrer.
Pourquoi : Cache le déséquilibre entre grosses et petites stories.
Bonne pratique : Suivre les Story Points ou les items entiers, pas les micro-tâches.
Pourquoi : Fait remonter la ligne réelle — signal trompeur.
Bonne pratique : Refuser l'ajout de scope, sauf renégociation du Sprint Goal.
Pourquoi : La règle est binaire : 0 % ou 100 % selon la Definition of Done.
Bonne pratique : Ne décrémenter le Burn Down que sur validation DoD.
Pourquoi : Signal d'un blocage majeur non traité.
Bonne pratique : Le Scrum Master doit lever l'obstacle immédiatement.
Pourquoi : Ré-introduit un pilotage temps qui fausse l'inspection empirique.
Bonne pratique : Préférer les Story Points ou le nombre d'items restants.
Pourquoi : Un Burn Down couvre un seul Sprint.
Bonne pratique : Utiliser un Burn Up ou un forecast Monte Carlo pour la release.
Pourquoi : Empêche l'auto-organisation et l'inspection collective.
Bonne pratique : Afficher visiblement (physique ou digital) pour toute l'équipe.
Pourquoi : Détruit la confiance dans les données.
Bonne pratique : Consigner les valeurs réelles, même mauvaises.
Pourquoi : Un Burn Down parfait est très rare et souvent artificiel.
Bonne pratique : Utiliser la ligne idéale comme repère, pas comme objectif contractuel.
Pourquoi : En début de Sprint, la ligne plate 1-2 jours peut être normale.
Bonne pratique : Lire la courbe globalement, pas au jour le jour.
Pourquoi : Ce sont deux artefacts différents, à horizons différents.
Bonne pratique : Nommer explicitement : Sprint Burn Down vs Release / Product Burn Down.
Pourquoi : Ignore la qualité, l'issue du Sprint Goal, la satisfaction.
Bonne pratique : Combiner Burn Down + Velocity + Sprint Goal + Retrospective.
Pourquoi : On mesure alors n'importe quoi comme « Done ».
Bonne pratique : Formaliser la DoD avant tout suivi Burn Down.
Pourquoi : Masque le vrai comportement du Sprint.
Bonne pratique : Toujours refléter fidèlement la réalité (scope inclus).
Pourquoi : Contredit l'esprit auto-organisé de l'équipe.
Bonne pratique : Un seul Burn Down par équipe, pour tout le Sprint.
9. Burn Down vs Burn Up
Le Burn Up Chart est le pendant du Burn Down : il montre le travail déjà terminé (courbe qui monte) ainsi que le scope total (ligne de scope). Son gros avantage : il rend le scope creep visible.
Le Burn Down cache le scope creep : la ligne réelle rejoint 0 mais on ne voit pas les items ajoutés.
| Critère | Burn Down | Burn Up |
|---|---|---|
| Ce qu'on visualise | SP restants | SP terminés + scope total |
| Direction | Descend vers 0 | Monte vers le scope |
| Scope creep visible ? | Non (indirect) | Oui (ligne de scope monte) |
| Horizon typique | Un Sprint | Sprint ou release |
| Public | Équipe Scrum | Équipe + stakeholders |
10. Burn Down vs Velocity
La Velocity mesure ce que l'équipe a livré à la fin d'un Sprint ; le Burn Down suit ce qu'il reste à faire pendant un Sprint. Ce sont deux outils complémentaires, jamais concurrents.
| Critère | Burn Down Chart | Velocity |
|---|---|---|
| Horizon | Un Sprint | Historique multi-Sprints |
| Nature | Suivi temps réel | Indicateur agrégé |
| Unité | SP restants | SP livrés par Sprint |
| Usage principal | Inspection & adaptation Daily | Prévision Sprint Planning |
| Fréquence de mise à jour | Quotidienne | 1 fois par Sprint |
| Signal détecté | Blocages, retard, scope creep | Tendance, stabilité, capacité |
| Public | Équipe Scrum | Équipe + stakeholders |
11. Burn Down vs Capacity
La Capacity est calculée avant le Sprint (Sprint Planning) ; le Burn Down suit la réalité pendant le Sprint. La Capacity dimensionne, le Burn Down vérifie.
| Critère | Burn Down Chart | Capacity |
|---|---|---|
| Question posée | Où en est-on aujourd'hui ? | Combien pourrons-nous faire ? |
| Moment | Pendant le Sprint | Avant le Sprint (Planning) |
| Unité | SP restants | Heures / personne·jours |
| Utilisé pour | Piloter l'avancement | Dimensionner le Sprint Backlog |
| Complémentarité | Vérifie la Capacity prévue | Alimente la Sprint Planning |
12. Burn Down avec Scrum
Bien que non obligatoire, le Burn Down s'insère naturellement dans les événements Scrum :
- Sprint Planning — fixe le point de départ (total SP embarqués).
- Daily Scrum — mise à jour quotidienne, support d'auto-inspection.
- Sprint Review — le graphique final illustre l'atteinte (ou non) du Sprint Goal.
- Sprint Retrospective — support factuel pour identifier des améliorations.
Le Burn Down est mis à jour par les Developers. Le Scrum Master peut aider à en faciliter la lecture. Le Product Owner le consulte comme n'importe quel stakeholder.
- Suivre l'avancement d'un Sprint
- Identifier un blocage tôt (courbe plate)
- Rendre visible le travail restant à l'équipe
- Suivre une release ou un projet
- Visualiser un scope creep explicite
- Communiquer aux stakeholders
- Prévoir le prochain Sprint
- Projeter plusieurs Sprints
- Comparer la stabilité de son équipe dans le temps
13. Burn Down avec Jira
Dans Jira Software (Scrum boards), le Burn Down est généré automatiquement à partir du Sprint Backlog. Pour l'activer et l'exploiter :
- Ouvrir le tableau Scrum > menu « Reports » > « Sprint Burndown Chart ».
- Sélectionner le Sprint actif.
- Configurer l'estimation (Story Points recommandé, pas les heures).
- Vérifier que les statuts « Done » correspondent bien à la Definition of Done.
- Afficher en Daily via un TV / un dashboard partagé.
14. Burn Down avec Azure DevOps
Azure DevOps propose un Sprint Burndown widget directement dans les dashboards. Étapes :
- Ouvrir « Boards » > « Sprints » > « Analytics ».
- Configurer l'unité (Story Points, Count of Work Items, ou Remaining Work).
- Épingler le widget au dashboard d'équipe.
- Pour la release : utiliser le Feature Burndown ou l'Analytics view avec Power BI.
15. Burn Down avec Excel
Pour une équipe qui débute ou sans outil dédié, Excel (ou Google Sheets) est parfait. Structure minimale :
| Colonne | Contenu | Formule |
|---|---|---|
| A | Jour (J0 à Jn) | — |
| B | SP idéaux restants | =$B$2 - (($B$2/Jn)*A) |
| C | SP réels restants | Saisie manuelle en Daily |
| D | Écart | =C-B |
Insérez ensuite un graphique en courbes sur les colonnes B et C. Vous obtenez un Burn Down professionnel en 5 minutes.
Testez vos connaissances
Le Burn Down Chart est-il un artefact officiel du Scrum Guide 2020 ?