Avant de dévoiler cette 3e règle, j’aimerais souligner qu’elle revêt pour moi une actualité toute particulière car je suis en pleine discussion sur ce point avec l’une des équipes avec qui je travaille. Ils se reconnaîtront 
. Pour être tout à fait transparent, c’est une discussion que j’ai avec beaucoup d’équipes mais pour des raisons différentes.
Règle n°3: Le burndown est publié tous les jours après le standup
Cette règle nécessite peut-être quelques explications sur SCRUM pour les lecteurs qui ne seraient pas familiers avec la méthode (est-ce le cas ?).
Le burndown est un indicateur permettant de suivre le reste-à-faire en cours de sprint. Chaque jour, l’équipe de développement ré-estime le travail restant pour atteindre l’objectif du sprint, et la somme de ce travail est indiquée sur une courbe. La courbe doit donc descendre si l’équipe progresse bien. Elle est habituellement accompagnée d’une ligne de projection idéale, tracée entre la somme des estimations initiales en début de sprint et la date de fin de sprint. 
Cette ligne idéale permet de juger approximativement de la bonne progression de l’équipe. Ce sont des temps de passage de référence, un peu comme dans un contre la montre à vélo ou une descente de ski. Le « reste à faire » peut-être évalué sous 2 formes : soit une estimation des tâches en jours/homme, soit une estimation des user stories (fonctionnalités) en points. Le burndown est remis à jour suite à la mêlée quotidienne de Scrum : le standup. Voilà pour l’explication de texte.
Le burndown était jusqu’à récemment un indicateur clé de la méthode Scrum, mais la dernière révision du Scrum Guide lui laisse une place plus discrète, au profit de la notion de reprévision du périmètre final d’un sprint. Cela ne change pas grand chose, si ce n’est que l’outil est remplacé par l’esprit : le Scrum Guide laisse le choix de l’outil qui permettra à l’équipe de suivre son avancement et faire une prévision de son atterrissage en fin de sprint, que ce soit un burndown, burnup, une courbe en S, une courbe de flux cumulés…
Pourquoi cette règle ?
Le burndown est un indicateur facile à produire et à mettre à jour: il n’y a pas de formule compliquée, la collecte des informations est triviale, et son tracé peut se faire à main levée. J’imagine que les créateurs de Scrum ont voulu garder une bonne balance entre simplicité et transparence maximum. Paradoxalement, je constate trop souvent l’absence de burndown affiché sur le mur des équipes agiles. Quand je pose la question, les explications tombent souvent dans l’une des deux catégories suivantes.
« Le burndown est dans Jira (ou VersionOne, ou …), il suffit d’aller le consulter »
Les outils électroniques facilitent et automatisent certaines tâches fastidieuses. Ils permettent aussi un meilleur partage des informations dans un mode distribué. Dernier avantage, ils contentent les amateurs de traçabilité. En revanche je trouve qu’ils ont tendance à dissimuler l’information car ils nécessitent l’accès à un ordinateur, et des comptes utilisateurs. D’autre part, ils sont en général peu souples sur le calcul des indicateurs : pour obtenir un indicateur correct il faut avoir saisi toutes les tâches et toutes les estimations depuis le premier jour, et certains n’aiment pas trop les ajustements : malheur à vous si vous ajoutez une tâche en milieu de sprint ou si vous retirez des stories, le résultat du tracé peut être… aléatoire. L’utilisation d’un outil électronique n’est pas une excuse pour ne pas afficher le burndown. Il suffit d’imprimer le graphique tous les jours et le scotcher bien en vue. On peut également préférer une technique moins gourmande en papier en traçant quotidiennement la courbe au crayon sur une seule feuille de papier (c’est d’ailleurs la façon dont il était utilisée initialement). Si la courbe n’est pas correctement tracée par l’outil choisi, cela prend 5 minutes pour faire une version manuelle.
« Ca ne sert à rien, on sait où on en est »
Deux gros problèmes avec cette explication, le premier c’est d’assumer que le burndown ne sert qu’à l’équipe de réalisation. Le burndown est un élément essentiel de transparence dans ET en dehors de l’équipe. Un burndown à jour et bien en vue évite un questionnement récurrent de la part des parties prenantes ou tout autre interlocuteur s’intéressant au déroulement de la réalisation. Il participe à instaurer une confiance entre l’équipe et son environnement. Si vous êtes Scrum Master et vous pensez qu’on ne viendra pas vous déranger pendant le sprint pour savoir où vous en êtes, vous sous-estimez la curiosité et vous sur-estimez la patience de votre Product Owner et de vos dirigeants.
Il se trouve parfois que cette deuxième explication n’est pas le fait d’une confiance excessive de l’équipe mais un symptôme visible d’un mal plus profond, comme par exemple un manque de discipline sur l’estimation en tâches ou en points. C’est le deuxième problème que j’ai avec cette excuse, le burndown ne joue pas son rôle de révélateur du déroulement du sprint. Une absence de burndown peut même être caractéristique d’une organisation défaillante. En rétrospective, il est utile pour visualiser et analyser ce qui s’est passé. Le fait même d’avoir en permanence son problème sous les yeux met une pression plus forte pour saisir le problème à bras le corps.
Il existe bien d’autres mauvaises-bonnes raisons pour ne pas publier son burndown, vous pouvez les partager avec nous. Scrum Master, cette petite discipline quotidienne ne te veut que du bien et ne coûte pas cher.
À venir:
Règle n°5: N’oublie jamais la valeur d’une user-story
Règle n°6: Une user-story trop grosse pour rentrer dans un sprint est une Epic
Règle n°7: Il faut pouvoir prendre plus de 4 user-stories par sprint