Guide de mêlée | 31. Comment créer et interpréter un burndown chart ?

Un burndown chart est relativement facile à créer. Il existe de nombreux outils disponibles pour le générer à partir du travail enregistré par les membres de l'équipe de développement. Malgré sa simplicité, son interprétation peut fournir des informations précieuses pour toute l'équipe Scrum. Lisez cet article pour savoir comment créer et interpréter un burndown chart.

Comment créer et interpréter un burndown chart ? - table des matières:

1. Comment créer un burndown chart ?
2. Qui est responsable du burndown chart ?
3. Comment interpréter un burndown chart ?
4. Burndown chart réel et idéal
5. Sélection de l'unité de mesure
6. Sommaire

Comment créer un burndown chart ?

L'équipe de développement doit surveiller son travail quotidien. C'est la base non seulement pour évaluer son efficacité mais aussi pour l'améliorer. Et l'un des outils les plus simples et les plus éprouvés à cette fin est le tableau de combustion.

Vous pouvez le créer manuellement en dessinant un système de coordonnées sur une feuille de papier. Sur l'axe Y, vous devez tracer la quantité de travail exprimée dans une unité choisie, par exemple, les points d'histoire. Sur l'axe des X, tracez une échelle indiquant les jours consécutifs du Sprint. Tracez une ligne du sprint idéal, puis marquez le nombre de tâches réalisées de manière réaliste pour chaque jour. Bien que cette solution soit charmante et engageante pour l'équipe, elle n'est pas très pratique. Il n'est pas non plus forcément adapté aux équipes distantes.

Par conséquent, les moyens numériques de créer un burndown chart sont beaucoup plus courants. De nombreux outils de journalisation du travail sur les tâches réparties entre les membres de l'équipe sont dotés d'une option permettant de créer automatiquement un graphique d'avancement. Ensuite, tout ce qu'un développeur a à faire est de marquer le début et la fin du travail sur une fonctionnalité particulière du produit, et sa contribution est reflétée dans le tableau de progression.

Avec les bons outils, il est également possible de mettre à l'échelle librement le graphique. Cela donne un aperçu de la combustion non seulement au niveau d'un Sprint donné mais aussi à l'échelle d'un trimestre ou de l'ensemble du projet.

Un facteur important à prendre en compte lors du choix d'un outil pour créer un burndown chart est son accessibilité à tous les membres de l'équipe Scrum. La visibilité du burndown chart pour l'ensemble de l'équipe de développement est un facteur clé de motivation. Tout aussi important est un regard quotidien sur la ligne indiquant le travail restant à faire. Parler de rodage pendant le Daily Scrum, amène les Développeurs à réfléchir à leur façon de travailler et à l'état actuel du Produit.

Qui est responsable du burndown chart ?

La question de la propriété du tableau des brûlures est quelque peu controversée. D'une part, il devrait appartenir au Scrum Master, car c'est un outil pour s'assurer que l'équipe travaille efficacement et conformément au plan. D'autre part, il doit rester entre les mains du Product Owner, car il reflète la progression vers un Objectif Produit qui est communiqué au Client. De plus, un tiers pour revendiquer sa propriété est l'équipe de développement car le graphique fonctionne comme son outil interne.

Le burndown chart est une mesure essentielle pour évaluer l'efficacité de l'équipe de développement et devient adopté par tous les membres de l'équipe Scrum. C'est pourquoi la transparence et l'accessibilité sont cruciales. Cependant, son but même est de servir l'équipe. Il est censé renforcer son auto-organisation, améliorer sa motivation et donner une image réelle de l'état d'avancement des tâches qui lui sont confiées. Par conséquent, en théorie, chaque membre de l'équipe de développement peut mettre à jour le burn chart.

En pratique, cependant, la tâche de mettre à jour le burndown chart incombe généralement au Scrum Master. Cela se produit surtout au début de son travail avec une nouvelle équipe de développement lorsque la vélocité de l'équipe est encore variable et difficile à estimer. Néanmoins, il est recommandé de déléguer cette tâche à l'un des Développeurs. Après tout, le tableau est censé être une mesure honnête et interne de l'avancement du travail tel que jugé par les développeurs eux-mêmes.

Comment interpréter un burndown chart ?

Nous avons décrit en détail l'apparence du burndown graph dans un article précédent. Ici, nous vous rappellerons seulement que l'axe X indique le temps restant pour terminer le travail. D'autre part, l'axe Y montre la quantité de travail restant à faire.

Burndown chart réel et idéal

Pour interpréter un burndown chart, l'élément clé n'est pas seulement le tracé régulier de la véritable « combustion », c'est-à-dire l'exécution des tâches par l'équipe de développement. Tout aussi importante pour l'image est sa comparaison avec la chute de ligne de combustion idéale (ligne directrice).

En comparant la ligne de brûlage idéale avec la réduction réelle du travail indiquée sur le tableau de brûlage, deux paramètres très importants peuvent être évalués. Tout d'abord, pour voir si le travail se poursuit au rythme actuel, l'équipe de développement atteindra l'objectif de sprint ou l'objectif de produit à temps. Deuxièmement, pour avoir une idée du moment où les travaux seront terminés tout en maintenant le rythme actuel. En d'autres termes, le burn chart montre le rythme réel des tâches, et la ligne idéale montre à quel rythme l'équipe doit travailler pour accomplir les tâches.

Le burn graph vous permet également de déterminer une valeur appelée Development Team Velocity sur le long terme. Nous y consacrerons un article séparé. Ici, nous mentionnerons simplement qu'il s'agit d'une valeur déterminée par la quantité de travail effectuée au cours d'un Sprint.

Grâce au fait que le burn chart illustre la comparaison d'une ligne de burn idéale avec une diminution réelle du nombre de tâches, il permet d' estimer le rythme de travail. Et ainsi anticiper les risques de retard des projets.

Sélection de l'unité de mesure

La vitesse de l'équipe est généralement mesurée en unités appelées points d'histoire. Il définit le nombre de user stories qui ont été réalisées. Ceux-ci peuvent nécessiter des quantités de travail très différentes.

C'est pourquoi de nombreuses équipes Scrum utilisent une mesure basée sur le temps. Selon l'échelle, il s'agit de jours ou d'heures-personnes. Chaque développeur estime puis enregistre le temps passé sur ses tâches.

Une autre option consiste à adopter les tâches comme une unité. Ce sont des unités légèrement plus grandes, qui à leur tour se voient attribuer une valeur exprimée en points d'histoire, ou en jours ou en heures-homme. C'est une unité qui permet au client de présenter de manière plus claire l'avancement des travaux sur le produit.

Quelle que soit l'unité de mesure, il convient de rappeler le principe de calcul de la vitesse de l'équipe de développement. Dans une journée ou un Sprint donné, seules les tâches réellement terminées comptent. Cela signifie que les tâches commencées seront comptées pour le lendemain ou Sprint même s'il ne manque que les tests finaux.

Sommaire

Avec les outils de surveillance d'équipe disponibles, la création d'un graphique d'avancement devient une tâche facile. La question la plus importante est d'assurer sa cohérence, sa clarté et son accessibilité à tous les membres de l'équipe Scrum.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit