Pour les équipes Scrum, le Burndown chart (graphique) est un outil de mesure visuel qui montre le travail restant à faire par rapport au taux d’achèvement prévu. Son objectif est de permettre au projet d’être sur la bonne voie pour fournir l’incrément attendu à la fin du sprint.
Le taux de progression d’une équipe Scrum s’appelle « vélocité ». Il exprime la quantité de story points complétés par itération. Une règle pour calculer la vélocité est que seuls les stories « finies » à la fin du sprint sont comptés. On ne comptera donc pas les travaux partiellement terminés (par exemple: codage terminé mais test manquant).
Après quelques sprints, on pourra probablement calculer la vélocité de l’équipe Scrum. Ensuite on pourra effectuer une estimation assez précise du temps nécessaire pour compléter toutes les entrées du backlog produit. Si la vélocité d’une équipe Scrum est par exemple 30 story points et qu’il reste 155 SP à accomplir, vous pouvez prévoir environ 6 sprints pour compléter toutes les stories.
« Il représente la tendance du « reste à faire » sous forme visuelle. L’axe horizontal représente les jours du sprint. L’axe vertical le travail à faire (exprimé en story points idéalement)«
Graphique de l’équipe au top
Ce diagramme est caractéristique d’une équipe capable de s’organiser. Cela indique un excellent product owner (PO) qui comprend la raison d’un backlog de sprint verrouillé et un excellent Scrummaster capable d’aider l’équipe. L’équipe ne s’est pas trop engagée et a « fini » le backlog de sprint dans les temps. L’équipe est également capable d’estimer sa capacité correctement. Aucune action corrective n’est nécessaire dans un tel cas.
Graphique de la « bonne équipe »
C’est une progression typique chez les équipes expérimentées. L’équipe a terminé son travail à temps et a atteint l’objectif du sprint. Ils ont également appliqué le principe de faire avancer les choses (en anglais: « get things done »), mais le plus important est qu’ils ont adapté l’étendue du sprint backlog pour terminer le sprint. À la fin, l’équipe a la possibilité de terminer des travaux supplémentaires. Lors de la rétrospective, l’équipe devrait discuter des raisons de la progression tardive dans la première moitié du sprint et résoudre les problèmes afin qu’ils soient meilleurs lors du prochain sprint. L’équipe doit également améliorer son évaluation de la quantité de travail qu’elle est capable d’absorber.
L’équipe « pas mal »
C’est là aussi un burndown chart typique que l’on peut observer dans de nombreuses équipes Scrum expérimentées. Le graphique indique à nouveau que l’équipe a été en mesure de mener à bien son engagement dans les délais. Ils ont adapté le périmètre ou ont travaillé plus dur pour compléter le sprint. L’équipe doit discuter sans tarder d’un changement de plan lorsqu’elle constate que les progrès ont ralenti depuis le début du sprint. En règle générale, on déplace un élément de priorité basse du backlog de sprint vers le prochain sprint ou vers le backlog du produit.
Trop tard
Ce graphique de burndown montre d’abord que l’équipe n’a pas tenu son engagement. Elle a été en retard durant tout le sprint. En outre, elle n’a pas adapté non plus le périmètre du sprint au bon niveau. Cela montre que l’équipe n’a pas terminé les stories qui auraient dû être divisées ou déplacées vers le prochain sprint. Dans une telle situation, on devra réduire la capacité du prochain sprint. Si cela se reproduit, ne pas hésiter à prendre des mesures correctives après quelques jours, lorsque les progrès sont plus lents que prévu. Par exemple, une manière de commencer est de déplacer les articles moins prioritaires vers le prochain sprint ou vers le backlog produit.
Trop tôt
L’équipe termine son travail plus tôt que prévu. Elle a terminé les stories, mais n’a pas travaillé sur d’autres items du backlog, même si elle avait la capacité de le faire. Elle a peut-être été trop conservatrice dans son estimation des stories lors du poker planning. Du coup, l’exécution des tâches est allée plus vite que prévu. En outre, une autre raison possible réside dans le calcul de la vélocité de l’équipe: On a retenu une valeur probablement inférieure à la réalité. Le ScrumMaster doit être proactif et aider l’équipe à s’améliorer, par exemple :
– En lui demandant de corriger l’estimation ou
– En s’assurant que l’équipe (en lien avec le Product Owner) rajoute des articles supplémentaires au sprint actuel.
Burndown « Vers L’infini et au delà »
Le premier burndown chart d’une jeune équipe Scrum ressemble généralement à ça. Il faut le prendre comme une précieuse source de connaissances car l’équipe a échoué de manière significative et très visible. Peut-être qu’une ou plusieurs partie(s) prenante(s) a demandé à rajouter des stories ou des tâches dans le backlog de sprint. Par ailleurs, une autre raison pourrait être qu’on a ré-estimé plusieurs fois les tâches pendant le sprint. L’erreur est que l’équipe n’a pas identifié le problème affiché par le graphique. Le backlog de sprint doit être réévalué et réorganisé immédiatement. Un coach peut être utile, mais déjà un Scrummaster et un Product Owner expérimentés peuvent souvent aider dans cette situation.
Et vous? Quelle est la forme de votre Burndown? A-t-elle évolué au fil des sprints? Ou bien utilisez-vous plutôt le Burnup? ACE MULTIPASS peut vous aider lors d’une ou plusieurs séances d’accompagnement à améliorer l’efficacité de vos sprints. N’hésitez pas à nous contacter.