Burndown Chart : lire les signaux de votre sprint

Le burndown chart est un graphique simple : deux axes, deux courbes, et chaque jour tu ajoutes un point. L'une des courbes c'est la théorie (combien de story points il devrait rester si tout se passait comme prévu), l'autre c'est la réalité (combien il en reste vraiment).

C'est un outil si simple que beaucoup d'équipes le traitent comme une corvée administrative. Mettre à jour le burndown, c'est un des trucs qu'on fait "parce qu'on est censé le faire". Mais un burndown bien lu n'est pas un tracker. C'est un miroir sur le sprint.

Pourquoi le burndown chart change la façon de lire un sprint

Un burndown rend visible ce qui resterait invisible sinon.[^1]

Quand on est dans le quotidien d'un sprint, on vit jour après jour. On finit une story, on en prend une autre. Est-ce qu'on est en bonne voie ? Personne ne le sait vraiment jusqu'à jeudi, quand on se rend compte qu'on va avoir du mal.

Le burndown, lui, le dit tous les jours. Dès le jour deux, si tu compares la courbe réelle à la théorique, tu sais s'il y a un écart. Dès le jour quatre, tu vois si cet écart se creuse ou se resserre. Et jeudi, tu as le temps d'agir si quelque chose ne va pas.

C'est ce feedback rapide qui crée la différence. Tu ne découvres pas à la revue du sprint qu'il manquait trois stories. Tu le sais à jour quatre et tu as le temps de décider : est-ce qu'on accepte que le sprint soit un peu court, est-ce qu'on ajoute une story mineure pour finir la journée, ou est-ce qu'on découvre un blocage qu'on doit résoudre ?

Comment construire un burndown chart

La structure est minimaliste. Tu crées un simple tableau avec trois colonnes.

Colonne 1 : les dates du sprint. Une ligne par jour.

Colonne 2 : le nombre théorique de story points qui devrait rester chaque jour. C'est une droite : au jour 1, tu as le total. Au jour 10, tu as zéro. Tu divises le total par 10 et tu remplis chaque ligne.

Colonne 3 : le nombre réel de story points qui reste. C'est ce que tu mets à jour chaque jour, en regardant le backlog du sprint et en comptant les points des stories qui ne sont pas "done". Les stories elles-mêmes viennent du PRD ou du backlog produit — si la priorisation n'est pas claire en amont, le burndown ne peut pas faire grand-chose (voir prd-le-guide-complet).

Tu traces deux courbes : la théorique et la réelle. Et tu la regardes émerger au fil des jours.

Les outils Scrum (Jira, Asana, etc.) la génèrent automatiquement.[^2] Mais comprendre comment la construire à la main aide à vraiment lire ce qu'elle dit.

Ce que les patterns de courbe révèlent

Une courbe réelle qui descend avec la théorique est idéale. L'équipe respecte son estimation et termine ses stories. Ça ne veut pas dire qu'il n'y a pas de friction, mais elle est gérée.

Une courbe réelle qui sort d'emblée au-dessus de la théorique (la courbe réelle part plus haut que le total aurait dû être) peut signifier : vous avez ajouté des stories en chemin, ou vous avez découvert des sous-tâches qu'on n'avait pas anticipées. Les deux cas, tu veux le savoir tôt.

Une courbe réelle qui descend vraiment lentement, puis rattrape juste à la fin, c'est souvent un signal : beaucoup de travail est "en cours" et pas "done". Le sprint a l'air d'avancer lentement, puis tout se finit les deux derniers jours. Ça veut dire qu'il y a probablement du travail en parallèle qui n'est pas vraiment compté, ou de la vérification à la fin. C'est un pattern à améliorer.

Une courbe réelle qui s'aplatit à un moment (aucun point n'est enlevé pendant deux jours) peut vouloir dire : une story s'est avérée beaucoup plus grande qu'estimée, ou il y a un blocage réel. Pendant le daily, tu interroges : pourquoi rien ne descend ?

Un écart qui se creuse et ne se resserre pas : tu dois agir. Soit réduire le scope du sprint, soit ajouter de l'aide à certaines stories, soit découvrir qu'il y avait une fausse estimation qu'il faut corriger.

Le burndown chart comme outil de conversation, pas de contrôle

Le burndown chart n'est pas "toi", c'est un tiers dans la conversation. Pendant le daily standup, au lieu de juste lister ce qu'on fait, on le regarde et on pose une vraie question : "regardez la courbe, ça correspond à ce qu'on pensait ?" Si non, pourquoi ?

C'est une façon de déplacer la conversation de l'administratif vers le stratégique. Au lieu de "Albert a fait ça, Bob a fait ça", c'est "on est en train de découvrir que cette story est plus grande qu'on pensait, qu'est-ce qu'on en fait ?"

Au long terme, sur plusieurs sprints, la comparaison des burndown charts aide à affiner la vélocité. Tu commences à voir : notre équipe est stable à 35 points par sprint, ou elle fluctue entre 25 et 45 selon les types de stories. C'est cette stabilité qui te permet de planifier la suite — et c'est un des rares indicateurs qu'une équipe peut vraiment piloter elle-même (voir comment-creer-vos-kpi).

Ce qu'il faut retenir

Le burndown chart est un signal en temps réel. Ce n'est pas un contrôle ni une obligation administrative. C'est une conversation visuelle avec le sprint.

Une équipe qui lit son burndown chaque jour sort des surprises de fin de sprint. Elle ajuste en temps réel. Et au fil des sprints, elle comprend son propre rythme et apprend à estimer plus justement.

---

[^1]: Dans le Scrum Guide (Schwaber & Sutherland), le burndown chart est présenté comme un artefact de transparence : il rend visible l'avancement réel de l'équipe face à l'objectif de sprint. scrumguides.org.

[^2]: Atlassian propose un tutoriel complet sur la lecture des burndown charts dans Jira, incluant les cas d'usage et les erreurs courantes d'interprétation. Tutoriel burndown charts Atlassian.