C’est un indicateur de mesure qui montre le travail restant sur une période donnée. Il permet de suivre le projet dans le temps afin de contrôler sa livraison dans les délais souhaités. Sur l’axe X s’affiche le nombre de jours que dure le sprint. Sur l’axe Y s’affiche l’effort en terme de story-points (ou de tickets) de l’équipe.
Deux lignes sont présentes : l’une représente le taux de progression idéal, l’autre le taux de progression de l’équipe. La barre de progression idéale sert de guide à l’équipe Scrum en lui montrant où elle doit en être.
Le taux de progression de l’équipe exprime le nombre de stories-points (ou de tâches) complétés par itération. Seules les tâches terminées à la fin de l’itération sont comptées.
Après quelques sprints, la vitesse d’une équipe Scrum sera très probablement prévisible et permettra une estimation assez précise du nombre points qu’elle produit durant un sprint.
Si la vitesse d’une équipe Scrum est par exemple de 20 points pour un sprint de deux semaines, et que la quantité totale de travail restant sur le projet est de 80 points, nous pouvons prédire qu’il nous faut environ 4 Sprint (soit deux mois) pour terminer toutes les user-stories dans le backlog.
Le burndown chart permet de visualiser les points restant à faire de l’équipe tout au long d’un sprint. Ces indicateurs de mesure s’affichent automatiquement sur l’outil JIRA.
Qu’est-ce que peut dire un burndown chart ?
Il indique ici que l’équipe n’a pas rempli son engagement. La courbe rouge indique qu’il reste 12 points sur les 26 points sur lesquelles s’est engagée l’équipe en début de sprint. Les tâches non terminées sont alors déplacées dans le prochain sprint.
Les pics de remontées indiquent que des tâches sont rajoutées par le Product owner durant le sprint. Cela peut être des bugs remontés par les utilisateurs. Les points ajoutés vont changer le périmètre du sprint. Si l’équipe s’est engagée sur 26 points et que le Product owner ajoute une tâche de 2 points et une autre de 3 points. Le nouveau périmètre sera de 31 points. Il est toujours utile lors de la planification de sprint, lorsque les développeurs s’engagent sur un certain nombre de points, de laisser quelques points exprès pour gérer les remontées de bug afin que l’équipe ne soit pas trop surchargée.
Sur ce burdown chart, la courbe du taux de progression de l’équipe est bien supérieure à la courbe idéale. 7 points ont été validées par l’équipe sur 28 points. Arrivé à la fin du sprint, l’équipe est loin d’avoir livré l’incrément de produit sur lequel elle s’est engagée.
Cela peut signifier plusieurs choses :
– L’équipe a accumulé de la dette technique
– Il n’y a pas eu de préparation du projet et donc pas de sprint 0
– La planification de sprint s’est faîte à la hâte et les critères fonctionnels présents dans les users-stories ont été négligés
– Ou des raisons purement humaines : des membres de l’équipe qui partent de l’entreprise, ect…
Dans celui-ci, l’équipe s’est engagée sur 25 points. Des tâches sont ajoutées par le Product owner et le périmètre du sprint se retrouve à 28 points. Aucune tâche n’est produite et validée par le Product owner avant les deux derniers jours de fin de sprint et la barre de progression de l’équipe descend d’un coup.
Même si finalement, l’incrément de produit est presque terminé, il n’est pas conseillé de valider les tâches au dernier moment du sprint, car le Product owner doit toutes les valider au dernier moment et l’on ne sait pas à l’avance si celui-ci aura le temps disponible pour tous faire. Cela peut signifier aussi que l’équipe a eu des problèmes techniques en début de sprint, que la réunion de planification a été mal préparée, ou dans le pire des cas qu’il y a eu une démotivation au sein de l’équipe.
Notons que les colonnes grisées représentent les week-ends. La courbe idéale est alors continue.
Pour ce dernier burdown chart, l’équipe suit plutôt bien la courbe idéale. Elle finit même en dessous de cette dernière entre le 15 et 16 octobre, entre le 17 et 18 octobre. Une courbe de progression qui serait toujours en dessous de la courbe idéale indiquerait que l’équipe estime mal les tâches ou que celle-ci à la possibilité de s’engager sur plus de points (donc de prendre plus de tâches à faire).
Enfin, la courbe de l’équipe termine au point 0, toutes les tâches ont été produites au cours du sprint.
