Le Burndown Chart

Ce graphique d’avancement montre la quantité de travail restant à faire sur une période donnée. Il permet de faire des pronostics sur la capacité de l’équipe à atteindre ses objectifs de sprint, de suivre l’avancement d’un sprint et également de visualiser d’éventuels blocages.

L’axe vertical (y) : il représente la quantité de travail, c’est à dire le nombre de points d’efforts à réaliser pour atteindre l’objectif du sprint.

L’axe horizontal (x) : il représente le temps, généralement les jours travaillés jusqu’à la fin du sprint.

La ligne directrice (en violet) : ce tracé correspond à l’avancement moyen du sprint. Il montre une approximation de l’endroit où l’équipe devrait se trouver dans le cadre d’une progression linéaire « idéale ». Ce tracé suppose que l’équipe travaille toujours à la même vitesse, ce qui est peu probable. Il n’a donc pas pour but d’être représentatif de l’état d’avancement au jour le jour du sprint, mais de situer l’état d’avancement global pour analyser d’éventuels blocages.

La courbe de progression (en bleu) : ce tracé correspond à l’avancement réel de l’équipe actualisé quotidiennement.

Quels avantages apporte-t-il ?

Le Burndown chart a de nombreux avantages tels que :

apporte de la transparence au sein de l’équipe
permet une visualisation efficace de l’état d’avancement du travail
permet à l’équipe de s’auto-gérer
est simple à comprendre et facile à mettre en place
permet de prendre du recul sur l’avancement du sprint et de prendre des décisions éclairées en conséquence

Comment mettre en place un Burndown Chart ?

Quel support utiliser ?

Le burndown graph peut être dessiné à la main sur un tableau blanc ou sur une feuille de papier. Il peut également être réalisé via des logiciels de feuille de calcul comme Excel, Google Sheet ou Numbers. Certains outils de suivi comme Jira permettent de le générer directement.

Quelles unités de mesure choisir ?

Il faut adapter vos unités de mesures en fonction de la manière de travailler de votre équipe et de votre besoin de manière à obtenir des résultats exploitables comme nous le verrons dans le cas n°6 !

Pour l’axe horizontal correspondant au temps. Selon le besoin on peut le mesurer en nombre de sprints, en jours (sous forme de dates réelles ou de numéro avec pour jour 1 le premier jour du sprint), en semaines etc. Vous pouvez laisser ou non les week-ends. Sans les week-ends la courbe est continue, sinon elle possède des paliers correspondant à l’inactivité pendant les week-ends. Vous pouvez également réaliser des burndown de release pour mesurer l’avancement d’un projet sur une plus grande période donnée.

Pour l’axe vertical qui correspond à la quantité de travail à fournir. Il existe différentes unités de mesures pour la définir : les story points, les points d’effort, les tâches techniques, les tickets, les heures de travail ou encore les user stories restants à valider. Pour quantifier la valeur apportée, certaines équipes choisissent d’utiliser la valeur business des user stories en unité de mesure.

Comment l’alimenter ?

Vous avez la structure de votre graphique, vos unités de mesure, il faut maintenant l’alimenter.

En début de sprint on définit la vélocité de l’équipe, c’est à dire la quantité de travail qu’est capable de fournir l’équipe sur un sprint. Ici on la mesure sous forme de story points. On place cette valeur sur l’axe vertical de notre graphique. C’est le point de départ de la ligne de progression. Ensuite, on ajoute la ligne directrice, correspondant à l’avancement idéal approximatif.

Pour pouvoir être construit, le burndown chart présuppose d’avoir défini lors du sprint planning les story points (ou autre mesure d’effort) sur l’ensemble des tâches prévues au cours du sprint.

Chaque jour, lors de la Daily, l’équipe actualise le graphique. Elle calcule la somme des story points des tâches terminées. On soustrait cette valeur à celle du jour précédent et on ajoute ce nouveau point au graphique.

<gif>

Le Burnup chart

On peut réaliser un burnup chart qui fonctionne à l’inverse du burndown chart. Celui-ci permet de visualiser le travail déjà réalisé plutôt que le travail restant à faire.

Si ces deux graphiques donnent la même indication, en général on va préférer utiliser le burndown chart pour suivre l’avancement d’un sprint car il permet à l’équipe de mieux visualiser le travail restant à faire. La courbe diminuant un peu plus chaque jour, elle est visuellement plus motivante à regarder qu’une courbe montante.

Cependant, le burnup chart est visuellement plus intéressant à utiliser pour le Product Owner dans certains cas, comme pour prédire la date de fin prévisionnelle d’une release, ce que l’on aborde dans le cas n°7 !

Quelques pistes d’analyse

Le Burndown chart montre la progression de l’équipe par rapport à l’objectif de sprint et facilite le suivi grâce à un outil visuel que l’on peut rapidement analyser pour en tirer des enseignements.

La vitesse de travail :

Le graphique d’avancement apporte des informations sur la vitesse à laquelle l’équipe travaille. Si vous remarquez que l’équipe termine systématiquement son travail plus tôt, cela peut montrer qu’elle peut engager davantage de travail lors de la planification du sprint. A l’inverse si l’équipe ne finit pas dans les temps, cela peut être le signe qu’elle s’est engagée sur une trop grosse charge de travail ou que le travail a été mal estimé.

Après quelques sprint, la vitesse (ou vélocité) de l’équipe sera plus facile à estimer. Ainsi si vos sont définis sur une durée de 2 semaines et que votre équipe possède une vélocité de 20 (c’est à dire la capacité de terminer 20 story points par sprint), on peut estimer qu’un projet composé de 80 story points devrait se terminer dans quatre sprints, soit deux mois.

Les points de bloquage :

Le graphique peut aussi relever des points de bloquages, une démotivation de l’équipe, une interférence de la part des parties prenantes etc. La retrospective permettra de faire le point en fin de sprint et d’analyser les raisons des bloquages et ralentissements rencontrés. Des solutions pourront ainsi être mises en place pour corriger cela lors du prochain sprint.

Cas n°1 : l’équipe a pris du retard

L’équipe a pris du retard tout au long du sprint et n’a pas rempli son objectif de sprint. Il reste 6 tâches non terminées, elles seront reportées sur le prochain sprint.