Burndown Chart
Le burndown chart est un indicateur agile qui représente
visuellement l'avancement de l'équipe agile lors d'un sprint,
ainsi que de l'évolution du travail restant afin d'atteindre
l'objectif de sprint.
Il est mis à jour quotidiennement durant le sprint lors du
daily Scrum.
Les points d'efforts comptabilisés sont généralement ceux
des items (les user stories) répondant à l'objectif du sprint,
bien que certaines équipes agiles préfèrent prendre en
compte dans le burndown chart les points d'efforts de
l'ensemble des éléments présents au sprint backlog.
Certaines équipes décident également de remplacer les
points d'efforts par la valeur business des user stories
composant le backlog du sprint, afin de piloter le projet par
la valeur. Au final, le choix vous revient.
Le burndown chart est un graphique réalisé par l'équipe de
développement quotidiennement, lors du daily scrum. Cet
indicateur est réservé à l'équipe de développement, et n'est
donc pas un indicateur de reporting à destination du
management.
Burndown de sprint vs Burndown de release : Quelles
différences ?
Le burndown chart de sprint est utilisé pour vérifier la charge
de travail restante dans un sprint afin d'atteindre l'objectif du
sprint, alors que le burndown chart de release permet de
visualiser le "reste à faire" avant de sortir la prochaine
release du produit.
Burndown chart vs Burnup chart : Quelles différences ?
Le burndown chart permet de visualiser le travail restant à faire dans le cadre d'un sprint, alors que le burnup chart permet de
visualiser le travail déjà réalisé par rapport à la globalité du projet prévu.
Le burndown chart se construit de la façon suivante :
1. Il est initié au début d'un sprint.
2. L'équipe estime les points d'efforts nécessaires pour
atteindre l'objectif de sprint.
3. Ce total des points d'efforts est le départ de la courbe
burndown chart, sur l'axe des ordonnées (axe vertical).
4. Chaque jour, l'équipe calcule la somme des points
d'efforts des éléments réalisés.
5. La somme du travail réalisé est soustrait aux points
d'efforts du jour précédent.
6. L'équipe de développement inscrit un nouveau point sur
le graphique.
7. Les étapes 4 à 6 sont répétées jusqu'à la fin du sprint.
1
Burn Up Chart
La burnup chart est un graphique qui montre la portée et la
progression d’un projet. C’est l’outil de gestion de projets idéal
pour suivre rapidement les étapes clés et mesurer efficacement les
progrès réalisés au regard de son périmètre.
Le burnup chart est un outil de reporting agile qui représente
visuellement l'avancement de l'équipe agile sur plusieurs itérations,
en parallèle avec le périmètre du projet.
Ce graphique se construit en mettant sur l'axe des abscisses (axe
horizontal) les différentes itérations, et sur l'axe des ordonnées (axe
vertical) le total des points d'efforts nécessaires pour réaliser
l'intégralité du backlog de produit.
On trace alors deux courbes :
 La première représente l'évolution du périmètre du
projet, à la hausse ou à la baisse.
 La seconde représente la vélocité de l'équipe, itération
après itération.
Le burnup chart est un outil très pratique pour apporter de la
prédictibilité à l'équipe Scrum ainsi qu'aux parties prenantes du
projet, et permet de visualiser d'un coup d’œil le travail accompli par
l'équipe et les éventuels problèmes de périmètre.
Qui fait le burnup chart ?
Le burnup chart est un graphique réalisé par l'équipe Scrum, et plus
particulièrement le Product Owner. Il est mis à jour à la fin de
chaque sprint pour tenir compte de la vélocité de l'équipe du
dernier sprint et de l'évolution du périmètre du projet.
Toutefois, l'équipe Scrum peut décider de donner cette
responsabilité non pas au product owner, mais à l'équipe de
développement.
A mon sens, c'est plus logique que le product owner garde la main
sur l'outil. Cela participe en effet à la construction de la vision
produit, qui est portée par le PO (Product Owner).
Comment réaliser un burnup chart ?
1. Le burnup chart se construit de la façon suivante :
2. Il est initié au début du projet, de la feature ou de la
release.
3. L'équipe Scrum choisit le périmètre à intégrer, puis
estime les points d'efforts nécessaires pour atteindre
l'objectif.
4. Le product owner trace alors une première courbe,
représentant la somme des story points des éléments
du product backlog. C'est l'objectif à atteindre.
5. A la fin de chaque sprint, il calcule la vélocité de l'équipe
par rapport à l'incrément de sprint, contenant des
éléments 100% terminés et respectant la definition of
done.
6. il reporte ensuite l'avancée de l'équipe sur une seconde
courbe, et ajoute la vélocité du sprint terminé à la
somme des précédents
Comment interpréter un burndown chart ?
Outre le fait de représenter visuellement l'avancée de l'équipe
au jour le jour dans un sprint et le travail restant à faire, l'équipe
Scrum peut tirer plusieurs enseignements à partir d'un
burndown chart.
Dans les différents exemples qui vont suivre, les courbes grises
et rouges représentent les valeurs suivantes :
 La courbe grise.
L'avancement idéal de l'équipe au fur et à mesure d'un
sprint. Ce n'est bien sûr pas atteignable, mais c'est une
courbe de référence.
 La courbe rouge.
Représente l'avancement et le "reste à faire" réel pour
l'équipe de développement sur le sprint en cours.
1 ) La courbe rouge est au-dessus de la courbe grise
L'équipe prend du retard régulièrement tout au long du sprint,
et risque ainsi de ne pas pouvoir livrer l'intégralité des user
stories qui se trouvent dans le sprint backlog.
Cela peut vouloir dire que :
 L'équipe a sous-estimé les éléments à développer et le
temps nécessaire pour les finir à 100%.
 L'équipe a été trop gourmande et a voulu prendre trop
de user stories d'un coup dans le sprint.
 L'équipe a du mal à finir ce qu'elle a commencé, ou fait
face à des difficultés opérationnelles.
 L'équipe n'est pas au complet (arrêt maladie, congés,
etc), et fonctionne au ralenti.
Une courbe comme ça devrait alerter l'équipe et les pousser à se
réorganiser afin de traiter les éléments permettant d'atteindre
2
Comment lire un burnup graph ?
Ce qui est intéressant avec le burnup chart, c'est qu'on peut en
déduire beaucoup d'informations à partir des deux courbes
représentées : l'évolution du périmètre et le travail accompli.
On peut ainsi visualiser les évolutions à la hausse ou à la baisse
(plus rare) du périmètre du product backlog. Je rappelle qu'une
évolution du périmètre est normal et souhaitable en agilité.
On peut également observer l'évolution de la vélocité de l'équipe
au fur et à mesure de l'équipe, et voir si elle est constante ou si
au contraire elle est en dent de scie. Dans ce dernier cas, ce
serait intéressant de creuser pour comprendre pourquoi.
Enfin, on peut également prédire une date de fin prévisionnelle
pour livrer un produit, une feature ou une release. C'est le
moment où les deux courbes se croisent.
Par extension, on peut également voir si l'équipe sera en mesure
de traiter l'intégralité du périmètre avant la date cible de
livraison ou pas. Dans le second cas, cela laisse la possibilité
d'adapter le périmètre de l'équipe si l'on ne souhaite pas décaler
la livraison.
Exemple 1
Ce que nous pouvons analyser en observant ce burnup :
 L’équipe a rapidement pris le rythme et même de
l’avance
 La bonne vélocité de l’équipe a permis d’intégrer des
fonctionnalités supplémentaires
 La livraison à la date souhaitée va être difficile sans
révision du périmètre à la baisse
Exemple 2
Ce que nous pouvons analyser en observant le burnup ci-dessous
:
l'objectif de sprint.  2 jalons de livraison sont identifiés (V1 / V2)
Ce point devrait être discuté en rétrospective.  La première version concerne le MVP, la seconde
2 ) courbe rouge est au-dessous de la courbe grise intègre le reste des fonctionnalités
L'équipe a pris de l'avance et atteindra l'objectif de sprint avant  Le périmètre du MVP a été enrichi (sprint 3) avant
la fin de celui-ci. C'est une bonne nouvelle ! d’être révisé (sprint 5)
Cependant, même si l'objectif est atteint, le sprint ne se termine  Le périmètre initial du MVP était parfaitement défini
pas plus tôt que prévu. L'équipe doit donc prendre en compte de  La vélocité réelle de l’équipe est inférieure aux
nouveaux éléments (user stories, bugs à corriger, spikes, etc) prévisions
afin de mettre à profit le temps restant.  La vélocité de l’équipe est en revanche relativement
Pour les sprints suivants, l'équipe devra sûrement revoir constante (meilleure prédictibilité)
l'ambition de son objectif de sprint à la hausse.  Le périmètre de la V2 a beaucoup augmenté. Là encore,
un retrait de fonctionnalité a été nécessaire pour tenir
3 ) La courbe rouge remonte
le planning
Rien d'alarmant. Cela signifie que le périmètre du sprint backlog
 Une courbe de prévision est ajoutée pour mieux
a évolué.
visualiser l’atterrissage au regard de la vélocité réelle de
Si la courbe remonte de manière trop brusque, cela peut vouloir
l’équipe. Afin de tenir compte de l’incertitude, une
dire que :
variation haute/basse peut être ajoutée à la prévision.
 L'équipe n'a pas bien estimé le travail à faire pour
réaliser les user stories du backlog.
 L'équipe n'a pas su dire non aux parties prenantes du
projet pour ajouter des fonctionnalités en cours de
sprint.
Dans le second cas, attention ! Seuls les éléments répondant à
l'objectif de sprint peuvent être ajoutés en cours de route au
sprint backlog. Les autres doivent être ajoutés au product
backlog, pour future estimation et priorisation.
4 ) La courbe rouge n'atteint pas 0 à la fin du sprint

Le burnup chart est créé à la fin du premier sprint afin de

représenter le travail accompli et de le comparer au travail à
réaliser. Il est par la suite mis à jour à chaque fin de sprint pour
suivre l'avancement de l'équipe Scrum.
Aïe ! L'objectif du sprint n'est pas atteint, l'équipe de
développement n'a pas su respecter son engagement.
Les causes principales sont les suivantes :
 L'objectif du sprint était trop ambitieux.
 L'équipe a très largement sous-estimé les points
d'efforts nécessaires pour terminer les éléments du
backlog.
 L'équipe a fait face à de nombreuses difficultés
opérationnelles et n'a pas su trouver les solutions
adéquates.
 La definition of done n'est pas réaliste.
 L'équipe a été réduite en cours de route (démission,
arrêt, congés, etc).
Dans tous les cas, ce point doit faire l'objet de la prochaine
rétrospective, afin d'analyser ce pourquoi l'équipe en est arrivé
là et ce qui peut être mis en place dès le lendemain afin de
corriger le tir.
5) La courbe rouge ne descend pas ou presque pas

Ce type de burndown chart nous montre que l'équipe rencontre

énormément de difficultés au quotidien pour terminer ce qu'elle
a commencé.

3
Elle peut faire face à des difficultés techniques, ou encore avoir
très largement sous-estimer les user stories à développer.
Ce point devrait être discuté en rétrospective.
6) La courbe rouge est stable et chute drastiquement au
dernier moment

Dans ce cas de figure, tous les éléments sont terminés en même

temps. Cela signifie que l'équipe de développement a lancé en
parallèle le développement de l'intégralité des user stories.
La bonne pratique serait plutôt de terminer ce qu'on a
commencé avant d'attaquer un nouveau sujet.
Ce point devrait être discuté en rétrospective.
Q : La sortie était prévue en quatre itérations. Que peut-on Q : La sortie était prévue en quatre itérations. Que peut-on
déduire du burndown chart ci-dessous ? Après la troisième déduire du burnup chart ci-dessous après la troisième
itération. (Sélectionnez deux) itération ? (sélectionnez Trois).

A. La version est en retard sur le calendrier

B. La version est en avance sur le calendrier.
C. 100 points d'histoire du travail sont en attente
A. La sortie est en retard.
D. 100 points d'histoire du travail sont terminés
B. 100 points d'histoire de travail est fait.
C. La taille de l'équipe est réduite à la troisième itération.
Q :La sortie était prévue en 4 itérations. Que peut-on déduire
du Burndown chart ci-dessous après la 3ème D. La vitesse de la deuxième itération était supérieure à la.
itération ? (sélectionnez Deux) D'abord

A. Le travail a été ajouté dans la 3e itération.

B. La sortie est en avance sur le calendrier.
C. L'équipe a une vélocité constante.
D. L'équipe était en avance sur le calendrier lors de la
deuxième itération.