Il est utilisé dans les méthodes Agile et notamment dans la méthode Scrum.
Le burndown graph vous permet de mesurer le degré d'avancement dans la réalisation des tâches et, s’il le faut, de rectifier le tir pour que le sprint soit fini dans les temps.
C’est une métrique fondamentale pour suivre l’avancement de l’implémentation d’un projet Agile.
Il permet également de montrer aux équipes l'utilité de faire un point tous les jours sur l'état de l'avancement des travaux, ces informations sont immédiatement affichées et accessibles à toutes les équipes qui participent au projet, et également au client. Il implique donc l’ensemble des participants au projet et contribue à l’engagement et à l’énergie de l'équipe.
Pourquoi utiliser un burndown graph ?
Disposer d'une vision rapide de l'avancement d'un sprint
Matérialiser la performance collective de l'équipe
Contrôler quotidiennement les progrès ou les retards et réajuster pour réduire les risques
Partager avec les équipes et les impliquer plus dans la réussite du projet (tout le monde peut participer à la planification et au suivi)
Maitriser visuellement son sprint et ainsi mieux l'exploiter
Le burndown graph est un indicateur visuel de la quantité de travail qui reste théoriquement à faire pour terminer le sprint
Il pousse à réestimer quotidiennement le reste à faire
Comment fonctionne un burndown graph ?
Il se compose ainsi:
L’axe des ordonnés (X) représente les jours du sprint
L’axe des abscisses (Y) représente les story points (ceux-ci peuvent se présenter en heures ou en jours selon vos préférences)
Une courbe de départ représentant la courbe « idéale »
Une courbe réelle que vous mettrez à jour quotidiennement en fonction de la progression des story points
La courbe de départ représente la courbe parfaite de votre sprint, mais attention, rien n’est jamais parfait et nous ne sommes pas des intelligences artificielles donc inutile de viser le suivi exact de cette courbe. Le but est de s’en rapprocher et de la coller de près tout au long du projet.
Le burndown graph est mis à jour à l'issue de chaque Scrum (mêlée quotidienne).
Comment créer un burndown graph?
Si toute l’équipe concernée par le projet est présente physiquement dans les mêmes locaux que vous ce n’est pas très compliqué. Il vous suffit de créer un burndown graph manuellement. Un simple tableau blanc ou un une grande feuille de papier suffisent pour dessiner votre graphique, l’afficher à la vue de tous et le mettre à jour quotidiennement.
Vous pouvez également le réaliser sur Excel ou tout autre logiciel permettant de réaliser un graphique, l’imprimer et l’afficher.
Si vos équipes sont éloignées (freelance, télétravail, plusieurs bureaux etc…) ou même si tout simplement vous préférez, des sites web ou des logiciels permettent de créer automatiquement des burndown graph.
Vous les partagez ainsi en ligne et il est alors facile pour tout le monde de travailler en mode collaboratif et de partager les différents indicateurs entre tous les membres de l’équipe où qu’ils soient.
La création d’un burndown graph commence toujours par une tâche d’estimation où vous attribuez un nombre de points ou d'heures par tâche.
C’est une activité qui doit se faire en équipe car chaque membre de l'équipe est impliqué dans l'estimation de chaque story. Quand on crée le planning nous avons besoin de savoir qui va, par exemple, développer ou intégrer telle partie de telle story. Les stories concernent plusieurs types d’expertise (codeur, intégrateur, testeur, etc…). Chaque membre doit avoir une vision globale du projet pour pouvoir faire une estimation au plus juste et bien comprendre chaque élément. De plus cette collectivité pousse les discussions et les débats en amont du projet sur les temps d’estimation. Si deux membres de l’équipe ne sont pas d’accord ils peuvent en débattre et donner leurs arguments.
Nous allons vous parler de la méthode qui, à notre sens, est la plus efficace pour réaliser des estimations de story de par son côté collaboratif, ludique et efficace.
Estimer les story points grâce au planning poker
Si vous demandez une estimation à l'équipe c’est tout naturellement la personne qui connait le mieux l'histoire qui va répondre. C’est une mauvaise façon de procéder car les autres membres vont être influencés par cette estimation qui n’aurait pas forcément était la leur.
Le poker planning va vous permettre d’éviter cela.
Règles du jeu :
Tous les membres sont invités à jouer pour estimer le temps nécessaire à l’ensemble de la story et non juste sur leur part de travail personnelle.
Chaque membre reçoit un jeu de 13 cartes de couleurs différentes.
Le chef de projet énonce la story qui doit être estimée.
Chaque membre de l'équipe sélectionne en secret une carte qui représente son nombre de points d’estimation (par exemple 20). Cette méthode pousse chaque membre de l'équipe à réfléchir seul à sa propre estimation et non à se référer à l'estimation d’un autre membre.
Ils la placent sur la table face cachée.
Une fois que tous les membres ont déposé leurs cartes sur la table ils les retournent en même temps.
Deux issues possibles :
Soit les estimations sont les mêmes pour tout le monde, tout le monde est d’accord sur le fait que la story mise en jeu vaut 20 points et on passe à la story suivante.
Soit il y a un gros écart entre les estimations et dans ce cas l'équipe discute. Chacun donne son point de vue, ses arguments pour expliquer son estimation. Certains défendent leur idée, d’autres contrecarre avec d’autres arguments, bref le débat est ouvert. A la fin des délibérations l'équipe rejoue à nouveau. La partie continue jusqu'à ce que les estimations concordent, ou du moins qu'elles soient sensiblement les mêmes.
Afin d’éviter une envie de précision inutile les cartes ont des suites de nombres qui ne sont pas linéaires (les plus grosses cartes passent de 13 à 20 à 40 à 100).
En effet certaine story ne peuve être estimée qu’à la louche et non à la minute près.
Si l’ensemble de l’équipe estime une story à 40 points c’est qu’elle représente une tâche compliquée, longue ou nécessitant des tests avant d’être validée.
Mettre des cartes entre 20 et 40, par exemple, reviendrait à peaufiner inutilement une estimation qui ne doit pas l’être. Il serait impossible de trouver un accord sur une estimation à 36, 38 ou à 40 points. Ce serait une perte de temps.
3 autres cartes sont disponibles dans le jeu :
La carte 0. Elle indique soit que la story a déjà était faite ou que la story est très rapide à traiter et ne prend que quelques minutes (ajout ou retrait d’un lien hypertexte par exemple).
La carte ?. C’est une sorte de « joker » que l’on peut utiliser quand vraiment on ne connait pas le sujet et qu’on n’a aucune idée d’estimation.
La carte « tasse de café ». Le membre qui présente cette carte indique aux autres qu’il souhaite faire une pause. A eux d’accepter ou non.
Comment interpréter votre burndown graph
Ca y est vous avez réalisé votre burndown graph et vous avez bien suivi les étapes suivantes :
Créer le burndown graph en début de sprint, en positionnant l'échelle de temps en abscisse, et le nombre d'heures total à produire par l'équipe en cours de sprint en ordonnée.
Animer la mêlée quotidienne.
Fait le point quotidiennement avec chacun des équipiers pour savoir ce qu’il lui reste à faire et calculer le reste à faire total des tâches du sprint.
Positionner un nouveau point sur le graphique, selon les avancements de chacun.
Tracer une ligne entre le point précédent et le nouveau point afin de dessiner votre courbe.
Maintenant il va falloir l’interpréter.
En général en démarrage de sprint, sur la première partie de votre graphique, la courbe réelle reste au-dessus de la droite idéale. Pas d’inquiétude, c’est normal puisque durant cette période, l’équipe prend connaissance des nouvelles tâches ou a commencé certaines tâches qui se révèlent plus compliquées que prévu.
Si tout se passe bien la descente s’accélérera après. La courbe réelle va repasser sous la courbe idéale dans la seconde partie du sprint, et sa descente s’accélèrera vers la fin.
En effet, durant la seconde période, les équipes de développement ont pris leurs marques, elles sont opérationnelles et connaissent le domaine fonctionnel. Elles sont donc plus efficaces et cela se traduit par une exécution des tâches beaucoup plus rapide.
EXEMPLES :
Le burndown graph parfait
Une telle courbe est tout simplement parfaite !
Elle montre que l’équipe a très bien maitrisé ses estimations et ses avancements dans les différentes stories attribuées à chacun.
Les points respectés :
Bonne estimation de chaque story
Pas de sur-engagement
Pas de retard
Pas d’avance
Maîtrise de chaque story et du projet global
Engagement de l’équipe et respect de leurs délais individuels
Bon suivi du chef de projet
Les points d’amélioration :
Aucun
Le burndown graph d’expert
Voici une courbe que l’on peut retrouver avec une équipe qui a de l’expérience. Pourquoi ?
Au 2/3 du sprint l’équipe revenait au niveau de la courbe parfaite et a fini le projet bien en dessous de l’objectif. Nous pouvons donc dire qu’au 2/3 du projet l’équipe avait fait le plus gros du travail et a fini « tranquillement » par des points plus simples laissant même de la marge pour d’éventuels imprévus de dernière minute.
Les points respectés :
Pas de sur-engagement
Maîtrise de chaque story et du projet global
Engagement de l’équipe et respect de leurs délais individuels
Bon suivi du chef de projet
Un travail rapide et efficace
Une marge de sécurité pour gérer les imprévus
Un engagement collectif sur l’objectif
Les points d’amélioration :
Rajouter des stories supplémentaires en fin de sprint afin de prendre un peu d’avance sur le projet si la marge de sécurité n’est pas utilisée
Le burndown graph "tendu"
Cette courbe peut faire peur au premier abord. Même si l’objectif est atteint dans les délais la progression est quand même « tendue ». Et pourtant elle montre le travail d’une équipe expérimentée. Contrairement à l’exemple précédent cette équipe a peut être décidé d’ajouter des stories en fin de sprint et a quand même réussi à finir à temps OU alors a posé ses marques et une fois à l’aise a accéléré sa rapidité de travail.
Les points respectés :
Pas de sur-engagement
Maîtrise de chaque story et du projet global
Engagement de l’équipe et respect de leurs délais individuels
Bon suivi du chef de projet
Un engagement collectif sur l’objectif
Utilisation optimale du temps pour ajouter des stories
Les points d’amélioration :
Un point en milieu de sprint permettrait de revenir sur la courbe idéale, en enlevant des stories faciles et rapides par exemple.
Une telle courbe en milieu ou au ¾ d’un projet peut être dangereuse et stressante pour un chef de projet ou pour un client. Il faut vraiment avoir une grande confiance en ses équipes.
Le burndown graph « à la cool »
Ok cette courbe est tout le temps en dessous de la courbe idéale et les délais sont respectés mais elle indique surtout que les story points ont été mal évalués et que l’équipe avait besoin de moins de temps que prévu pour réaliser ce sprint. L’équipe a bien travaillé mais a surtout travaillé en dessous de ce qu’elle aurait pu faire. Beaucoup de temps a été perdu sur l’ensemble du projet.
Les points respectés :
L’équipe a fini son travail dans les temps
Les points d’amélioration :
Bien estimer les story points, ici visiblement sur évalués (revoir les parties de poker)
Mieux maîtriser chaque story et le projet global
Demander à l’équipe d’anticiper l’ajout d’autres stories sur ce sprint
Revoir le suivi du chef de projet qui aurait dû réadapter le Burndown Graph en ajoutant de nouvelles stories
Revoir l’effectif de l’équipe qui est peut être surestimé pour ce projet
Le burndown graph « sauve qui peut ! »
En voyant une courbe comme celle là on se dit, soit, que l’équipe se dit qu’un graphique parfaitement carré ça fait joli sur le mur, soit personne n’a fait ce qu’il fallait !
Personne ne l’a rempli et tout le monde s’est réveillé à la fin et il n’y a donc eu aucun suivi pendant le projet ?
Le chef de projet a rajouté des stories toutes les semaines ce qui fait que le travail restant reste supérieur au travail réalisé ?
Bref il faut tout revoir.
Les points respectés :
AUCUN
Les points d’amélioration :
Ne pas surestimer les stories ou arrêter d’en rajouter si la courbe ne descend pas et n’est pas en dessous des prévisions.
Ne jamais laisser à l’abandon un burndown graph, sinon ce n’est pas la peine d’en faire
Obliger les équipes à bien remplir chaque jour l’avancement de leur backlogs c’est la clé du graph !
Revoir le suivi ou l’absence de suivi du chef de projet qui aurait dû ré adapter le burndown graph ou secouer ses équipes pour remplir leurs données
Reprendre tout le sprint si la courbe se maintient ainsi au moins 3 jours consécutifs afin d’analyser d’où vient le problème
AUTRE SCENARIO
Le même exemple sauf que là le sprint n’a même pas été finalisé. Si vous vous retrouvez un jour face à une telle courbe, rien à faire… revoyez les bases de la gestion de projet !
Le burndown graph « y’a-t-il un pilote sur ce projet ? »
Bon là c’est sûr, soit le chef de projet a 5 ans et il fait du gribouillage soit quelqu’un essai de saboter votre projet ! Une telle courbe ne peut pas exister dans la gestion de projet. Il faut tout revoir.
Les points respectés :
Inutile de répondre à cette question
Les points d’amélioration :
A part tout ?... TOUT !
Revoir les bases entièrement
S’occuper de la mise à jour du graph
Si c’est le cas revoir les estimations ou les ajouts intempestifs de stories
Ré estimer les stories
Vérifier que chaque membre rentre bien ses données tous les jours
Chercher le problème dès le début. Le problème est déjà bien visible dès le 3ème jour du sprint. Cela doit être une alerte pour tout revoir.
Le burndown graph « scénario catastrophe»
Sur cet exemple non seulement la courbe a eu beaucoup de retard tout au long du sprint mais en plus l’objectif n’a pas été atteint. L’équipe était tout le temps en retard et le sprint n’a pas été réajuster pour pallier au problème.
Les points respectés :
Malheureusement pas assez pour aboutir à une réussite
Les points d’amélioration :
Bien estimer les story points, ici visiblement sous-estimés (revoir les parties de poker)
Mieux maîtriser chaque story et le projet global
Demander à l’équipe d’anticiper le retrait de stories sur ce sprint
Revoir le suivi du chef de projet qui aurait dû réadapter le burndown graph en supprimant des stories faciles ou rapides à exécuter
Vérifier que personne n’a ajouté des stories en cours de route et a ainsi surchargé les équipes qui n’ont pas pu remplir leurs objectifs
Revoir l’effectif de l’équipe qui est peut être sous-estimé pour ce projet
Le burndown graph « c’est bien mais ça pourrait être mieux !»
Top ! On pourrait qualifier ce genre de courbe de parfaite. La courbe réelle est bien plus basse que celle estimée et le sprint a été finalisé avec presque une semaine d’avance. Et pourtant…
Cette courbe nous montre certains dysfonctionnements comme une sur estimation des stories ou un mauvais réajustement du sprint. Mais surtout elle nous montre que pour le même temps vous auriez pu en faire beaucoup plus et que par conséquent vous avec perdu du temps.
Les points respectés :
Finalisation du sprint en avance, le client va être content !
Les points d’amélioration :
Bien estimer les story points, ici visiblement sous-estimés
Mieux maîtriser chaque story et le projet global
Demander à l’équipe d’anticiper l’ajout d’autres stories sur ce sprint
Revoir le suivi du chef de projet qui aurait dû réadapter le burndown graph en ajoutant des stories au sprint
Revoir l’engagement et la motivation de l’équipe sur l’avancement global du projet
Revoir l’effectif de l’équipe qui est peut être surestimé pour ce projet
Maintenant le burndown graph n’a plus aucun secret pour vous. Vous pourrez gérer vos projets de plus près et plus sereinement. Agir quand il le faut, rectifier, adapter, anticiper, maitriser, partager, impliquer et surtout réussir…
Le burndown graph est l’un des ingrédients pour qu’un projet se passe bien, utilisez le sans modération il peut devenir votre meilleur allié.
FIDESIO, vous accompagne dans la création de site internet: étude, UX, conception, design, développement, SEO.
Notre agence web est capable de répondre à tous vos besoins et d'élaborer une véritable stratégie digitale.
N'hésitez pas à nous contacter.