Qu’est-ce qu’un burndown chart et comment l’utiliser ?

Mesurer au quotidien l'avancement du travail à réaliser est primordial sur un projet. Vous serez tous d'accord avec moi sur ce point.

Mais comment fait-on avec les méthodes agiles afin de mesurer l'avancement du travail dans un sprint ? On utilise un outil graphique qui s'appelle le burndown chart.

Je vous explique en détails dans l'article ce qu'est le burndown chart, et quand et comment l'utiliser.

Qu'est-ce qu'un 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.

Ce graphique se construit en mettant sur l'axe des abscisses (axe horizontal) les différents jours composant le sprint, et sur l'axe des ordonnées (axe vertical) le total des points d'efforts des éléments permettant d'atteindre l'objectif du sprint.

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.

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.

Avantages du burndown graph

Le burndown chart est une notion intéressante pour l'équipe Scrum, qui apporte son lot d'avantages :

• L'équipe visualise le travail déjà réalisé et le reste à faire.
  D'un coup d’œil, l'équipe visualise au jour le jour le travail réalisé ET le reste à faire d'ici à la fin du sprint.
  
• Ajoute de la transparence dans l'équipe Scrum.
  Tous les membres de l'équipe Scrum peuvent visualiser la burndown chart et tous ont le même niveau d'information.
  
• Permet de prendre des décisions pour terminer le sprint à partir de faits avérés.
  Le burndown chart permet l'empirisme, et donne ainsi à l'équipe la possibilité de prendre sans attendre une décision pour le bien du projet.
  
• L'équipe peut s'auto-inspecter.
  Plus besoin que le chef de projet fasse un reporting et d'attendre ensuite la décision du management. L'équipe est autonome sur son organisation.
  
• Permet à l'équipe de visualiser son avance ou son retard.
  Cet outil graphique permet de faire des projections afin de voir où en sera l'équipe à la fin du sprint par rapport à l'objectif de sprint.
  
• Simple à comprendre, simple à réaliser.
  Enfin, la burndown chart est simple et rapide à faire, et se lit et s'interprète sans avoir besoin d'un manuel d'utilisation complexe.
  

Qui fait le burndown chart ?

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.

Quand doit-on faire un burndown chart ?

Le burndown chart est initié au démarrage d'un nouveau sprint agile, puis est mis à jour par l'équipe de développement quotidiennement, soit au début soit à la fin du Daily Scrum, afin d'éviter de perturber ce rituel agile.

Chaque jour, l'équipe de développement va calculer la somme des points d'efforts des éléments terminés (selon la definition of done), et les soustraire au total des points d'efforts à réaliser. 

La courbe du burndown chart va donc progressivement descendre, représentant ainsi la charge de travail restante à réaliser afin d'atteindre l'objectif de sprint.

Comment fonctionne un burndown chart ?

Le burndown chart est un graphique qui représente en abscisse les jours compris dans un sprint, et en ordonnées le total des points d'efforts à réaliser pour atteindre l'objectif d'un sprint.

La courbe tracée représente ainsi l'évolution du "reste à faire", au fur et à mesure des avancées de l'équipe. Cette courbe est mise à jour quotidiennement par l'équipe de développement.

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.
   

La courbe d'un burndown chart peut-elle monter ?

Logiquement, on devrait s'attendre à ce que la courbe descende chaque jour, puisque chaque jour l'équipe avance vers l'objectif du sprint : il y a donc de moins en moins de travail à réaliser.

Pourtant, la courbe d'un burndown chart peut monter. Comment est-ce possible ?

Le périmètre d'un sprint étant variable, l'équipe Scrum peut décider d'ajouter un ou plusieurs items au sprint backlog afin d'atteindre l'objectif du sprint. Ces items représente des points d'efforts supplémentaires pour l'équipe, ce qui se répercute sur la courbe du burndown chart.

En effet, dans les méthodes agiles et dans Scrum, le périmètre (ou backlog) d'un sprint ET d'un projet est variable. Il est dynamique, et émerge avec le temps et en fonction des besoins.

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 l'objectif de sprint.

Ce point devrait être discuté en rétrospective.

2 ) La courbe rouge est au-dessous de la courbe grise

L'équipe a pris de l'avance et atteindra l'objectif de sprint avant la fin de celui-ci. C'est une bonne nouvelle !

Cependant, même si l'objectif est atteint, le sprint ne se termine pas plus tôt que prévu. L'équipe doit donc prendre en compte de nouveaux éléments (user stories, bugs à corriger, spikes, etc) afin de mettre à profit le temps restant.

Pour les sprints suivants, l'équipe devra sûrement revoir l'ambition de son objectif de sprint à la hausse.

3 ) La courbe rouge remonte

Rien d'alarmant. Cela signifie que le périmètre du sprint backlog a évolué.

Si la courbe remonte de manière trop brusque, cela peut vouloir dire que :

• 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

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é.

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.

Peut-on utiliser un burndown chart avec d'autres méthodologies que Scrum ?

Le burndown chart n'est pas un outil réservé à Scrum. Vous pouvez l'utiliser avec d'autres méthodes agiles telles que Kanban, Extreme Programming (XP), LeSS, SAFe, ou encore Lean.

Le principe reste le même : représenter de manière simple et visuelle l'avancement du travail réalisé et le reste à faire dans le cadre d'une itération (d'un sprint).

Le burndown chart est-il utilisé pour du reporting ?

Cet indicateur est réservé à l'équipe Scrum. Il ne s'agit pas d'un indicateur de reporting. L'équipe Scrum étant auto-gérée, elle est la plus à même de prendre les décisions qui s'imposent afin d'atteindre l'objectif du sprint. Cela permet d'éviter des pressions inutiles de la part du management.

Les limites du burndown chart

Le burndown chart, malgré sa simplicité d'usage et de réalisation, présente toutefois quelques limites, qu'il est nécessaire de connaître.

• Le burndown chart est par nature imprécis, les estimations étant imparfaites.
  L'être humain est mauvais pour estimer avec précision le temps nécessaire pour réaliser une tâche. Les story points fonctionnent mieux que des jours homme, mais sont tout de même soumis à des biais.
  
  Le burndown chart reste donc un indicateur pour l'équipe mais ne peut pas être utilisé dans le cas d'un reporting.
  
• Il ne représente que l'évolution du travail restant à réaliser dans le cadre d'un sprint, pas dans un projet.
  Le burndown chart existe dans le cadre du sprint en cours. Il représente le "reste à faire" pour l'équipe d'ici  à la fin du sprint. Le backlog du produit, listant les fonctionnalités à inclure
  
• Il ne représente pas la capacité de travail réelle de l'équipe.
  Le burndown chart n'évolue pas de manière linéaire, toutes les user stories à traiter n'étant pas similaires en terme d'estimation. On ne peut donc pas s'y fier afin d'identifier la capacité réelle de l'équipe.
  
  Pour cela, il y a un autre indicateur qui existe : la vélocité de l'équipe.
  
• Il ne permet pas de prédire avec fiabilité la suite du projet.
  On peut visualiser via un burndown chart si l'on est en avance ou en retard sur un projet, et on peut même faire des projections pour la fin de sprint.
  
  Mais cela reste une estimation. On ne peut donc pas prédire avec efficacité comment la fin du sprint va se dérouler.