Le burn down chart : lire un sprint d’un coup d’œil
Un burn down chart trace le travail restant d’un sprint, jour après jour, face à une ligne idéale. Comment lire ses formes, ses limites, et comment Prior le dessine.
Un burn down chart montre, jour après jour, la quantité de travail qui reste dans un sprint. La courbe doit descendre vers zéro le dernier jour. Si elle passe sous la ligne idéale, l’équipe est en avance. Si elle passe au-dessus, l’équipe est en retard.
Ce que c’est
C’est un outil classique des équipes Scrum. Le Guide Scrum cite les burn down, les burn up et les diagrammes de flux cumulés comme des moyens de prévoir, et précise qu’aucun ne remplace l’empirisme : vous décidez toujours à partir de ce qui s’est réellement passé.
Le graphique compte deux lignes sur une grille. L’axe horizontal représente les jours du sprint. L’axe vertical représente le travail restant, le plus souvent en story points. La ligne idéale est droite : elle va du travail engagé le premier jour jusqu’à zéro le dernier jour. La ligne réelle montre ce qui reste vraiment. Avec des story points, le travail ne sort de la ligne que lorsqu’une story est terminée : la ligne réelle avance donc par paliers.
Pourquoi ça marche
Un burn down chart est un outil de suivi de progression que toute l’équipe peut voir. Dans une méta-analyse de 2016 portant sur 138 expériences et 19 951 personnes, Benjamin Harkin et ses collègues ont montré qu’inviter les gens à suivre leur progression vers un objectif améliore l’atteinte de cet objectif (d+ = 0,40), davantage encore quand la progression est consignée physiquement ou communiquée publiquement (Psychological Bulletin). La plupart des études portaient sur des objectifs de santé personnels : l’application au travail d’équipe est donc une inférence, mais le mécanisme est le même. Quand la progression est sous vos yeux, vous corrigez plus tôt.
Le moment est la seconde raison. Une équipe qui voit qu’elle est en retard dès le jour 3 peut découper une story ou demander de l’aide. Une équipe qui le découvre au jour 9 ne peut plus que retirer du travail.
Comment le lire
Comparez la ligne réelle à la ligne idéale, puis regardez sa forme.
| Forme | Ce que cela signifie souvent |
|---|---|
| Au-dessus de la ligne idéale dès le début, sans se rapprocher | Le sprint contient plus que ce que l’équipe peut faire, ou les estimations étaient trop basses. |
| Plate, puis une chute dans les derniers jours | Les stories ont été démarrées ensemble et terminées ensemble. Le travail ne se termine pas au fil des jours. |
| Un palier vers le haut | Du travail a été ajouté au sprint après son début. |
| Sous la ligne idéale tôt dans le sprint | L’équipe est en avance, ou elle s’est engagée sur trop peu. |
| Plate alors que tout le monde est occupé | Les stories sont trop grosses pour être terminées, ou elles sont bloquées. |
Ce sont des lectures courantes, pas des règles. Le graphique vous dit où regarder. Seule l’équipe peut dire pourquoi.
Un burn up chart trace deux lignes au lieu d’une : le travail terminé, qui monte, et le périmètre total, qui a sa propre ligne. Quand quelqu’un ajoute du travail, la ligne du périmètre monte d’un cran et cela se voit. Dans un burn down chart, le travail ajouté et le travail terminé se compensent sur la même ligne : un passage à plat peut donc vouloir dire l’un ou l’autre. Le burn up chart les garde séparés, ce qui le rend plus lisible quand le périmètre change.
Prenons une équipe qui s’est engagée sur 40 points en 10 jours. La ligne idéale dit qu’il devrait rester 20 points au jour 5. La ligne réelle en indique 31. L’équipe regarde son tableau et trouve deux stories de 8 points en cours, toutes deux en attente de relecture. Elle en termine une, découpe l’autre, et au jour 8 il reste 14 points contre 8 en théorie. À la revue de sprint, il reste une story de 5 points, que l’équipe sort du sprint avec l’accord du product owner.
Comment l’utiliser
- Figez le périmètre le premier jour. La ligne idéale part de ce que l’équipe a décidé d’engager.
- Passez les stories à terminé quand elles le sont vraiment. Le graphique ne baisse qu’à ce moment-là.
- Regardez-le à la mêlée quotidienne. D’un coup d’œil : en avance, dans les temps ou en retard.
- Quand vous êtes en retard, cherchez pourquoi. Cherchez les stories bloquées ou trop grosses. Demandez quoi, pas qui.
- À la revue, regardez la forme d’ensemble. Un milieu plat suivi d’une falaise à la fin est un schéma à travailler au sprint suivant.
Les erreurs à éviter
- Prendre la ligne idéale pour un objectif. Le travail réel n’est pas linéaire. Une ligne un peu au-dessus de l’idéale au milieu du sprint est normale.
- Laisser des stories en cours. Beaucoup de stories à moitié faites donnent une ligne plate et une falaise. Terminez avant de commencer.
- Modifier les estimations pour flatter la courbe. Redimensionner le travail en plein sprint cache ce que le graphique est censé montrer.
- Masquer les changements de périmètre. Si du travail est ajouté, dites-le. Un burn up chart le montre.
- Se servir du graphique comme d’un bulletin de notes. Un graphique utilisé pour juger l’équipe pousse chacun à ne plus rapporter honnêtement.
- Laisser des stories sans estimation. Le graphique ne peut pas compter ce qui n’a pas de taille.
Quand ce n’est pas le bon outil
- En flux continu. Sans sprint, il n’y a rien à faire descendre. Regardez plutôt le temps que prennent les éléments, ou un diagramme de flux cumulé.
- Pour de très petits sprints. Avec cinq stories, la ligne bouge en quelques grands paliers. Comptez les stories.
- Quand rien n’est estimé. Comptez les tickets à la place. Prior le fait pour vous.
- Quand l’objectif est une longue échéance fixe. Un burn up chart pour toute la version montre le périmètre et l’avancement sur plusieurs mois.
Dans Prior
Dans un projet Scrum, ouvrez l’onglet Sprints. Le Graphique d’avancement se trouve au-dessus des cartes de sprint.
- Choisissez le sprint. Le graphique s’ouvre sur le sprint en cours, ou sur le dernier sprint terminé.
- Changez de vue. Burn down | Burn up.
- Burn down trace le travail Reste (périmètre moins ce qui est fait) et une ligne Idéal en pointillés, du périmètre engagé le premier jour jusqu’à zéro le dernier jour.
- Burn up trace ce qui est Fait, le Périmètre total, qui monte ou descend d’un cran quand du travail est ajouté ou retiré, et la ligne Idéal de 0 jusqu’au périmètre engagé.
- Aujourd’hui est repéré, les jours à venir sont vides, et seule la ligne idéale va jusqu’au bout.
- Unité. Le graphique compte des story points dès qu’un ticket du sprint a une estimation. Sinon il compte des tickets et affiche En tickets (rien d’estimé).
- Détails. Survolez ou touchez un jour pour voir ses valeurs, et utilisez les flèches du clavier quand le graphique a le focus. Un lecteur d’écran reçoit un résumé en une phrase et un tableau masqué de tous les jours.
Le graphique se recharge quand un ticket du sprint change de statut, de points ou de sprint.
Deux limites à connaître. Pour un projet enregistré sur les serveurs de Prior, le graphique rejoue l’historique de vos tâches : chaque jour montre donc les points et l’état d’avancement que ces tâches avaient ce jour-là. L’appartenance à un sprint n’a pas d’historique, donc le périmètre correspond aux tickets actuels du sprint : un ticket que vous retirez du sprint disparaît aussi des jours passés, et un ticket ajouté tard apparaît à partir du jour de sa création, pas du jour où il a rejoint le sprint. Pour un projet personnel, ou quand Prior ne peut pas joindre le serveur, le graphique est construit à partir des tâches telles qu’elles sont maintenant et il est marqué Estimé : un ticket terminé compte le jour de sa dernière modification, et les réestimations ne sont pas connues.
Voir Graphiques d’avancement pour la référence, et Cycles et sprints pour configurer un sprint.