Publié par

Il y a 7 années -

Temps de lecture 5 minutes

Scrum Master Academy – Règle n°3 – Le burndown est publié tous les jours après le standup


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

Publié par

Publié par Gilles Mantel

J'ai 13 ans d’expérience professionelle. Je suis impliqué sur des projets itératifs et offshore depuis 2001 et j'y ai occupé tour à tour les postes d'ingénieur qualité, responsable des tests, analyste fonctionnel, et directeur de projet. Je forme et j'accompagne les clients de Xebia dans l’adoption de méthodes agiles (SCRUM, XP) et de pratiques d’ingénierie pilotées par les tests (TDR, ATDD). J'ai développé mon expertise au travers d’interventions dans des domaines métiers aussi variés que l’industrie, l’e-commerce, l’édition logiciel, le luxe, le public, les télécoms, ou les banques d’investissement. J'intervient régulièrement dans les conférences traitant de l'agilité et des tests depuis 2008.

Commentaire

2 réponses pour " Scrum Master Academy – Règle n°3 – Le burndown est publié tous les jours après le standup "

  1. Publié par , Il y a 7 années

    Je suis partisan du burndown original, celui manuel sur une feuille de papier unique mis à jour quotidiennement.

    Sur l’intérêt d’afficher le burndwon :
    – Quand je travaillais sur un projet au forfait géré dans nos locaux, j’en étais venu à me dire qu’il ne servait à rien, dans la mesure où il n’était visible et vu que par l’Equipe.
    – Mon projet actuel est développé dans les locaux du client, historiquement « traditionnel », qui passe aujourd’hui à l’agilité. Le burndown est vu par l’Equipe, par celles aux alentours, par les managers et par d’autres personnes curieuses. Pour l’Equipe, l’intérêt est toujours mineur. En revanche, le burndown est un formidable outil de communication et de présentation de la méthode. C’est un point d’entrée emblématique qui permet d’enchaîner sur la notion de vélocité et sur la gestion de l’avancement du projet (à l’échelle du sprint). Pour les managers c’est un indicateur rapide à visualiser.

    Quel que soit le contexte (« à domicile » / « à l’extérieur »), je vois quand même un gros inconvénient au burndown : la courbe idéale est lissée. Conséquence : l’influence des absences est biaisée, en particulier en début de sprint, et la courbe du reste-à-faire s’avère parfois trop optimiste par rapport à la réalité, ce qui peut constituer un risque pour la fin du sprint.

    ++

  2. Publié par , Il y a 7 années

    Bonjour Jeremy, merci de votre commentaire. Aucun indicateur n’est parfait, le burndown a ceci d’intéressant qu’il est simple et rapide à produire ce qui permet de s’accommoder de ses défauts. Comme tout indicateur, il nécessite une explication de texte si le tracé est « anormal ». NB: rien ne vous empêche de faire une courbe idéale non lissée, en prenant en compte les absences, mais c’est tout de suite plus compliqué ;)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.