Guide de mêlée | 32. Avantages et inconvénients du burndown chart

Le burn chart présente de nombreux avantages. C'est l'un des principaux outils de métriques de Scrum pour plusieurs raisons. Il est facile à créer, à mettre à l'échelle et à lire. Cependant, il présente également des inconvénients qui en font un outil peu universel. Dans l'article d'aujourd'hui, nous abordons le sujet des inconvénients et des avantages du burndown chart.

Avantages et inconvénients du burndown chart – table des matières :

1. Introduction
2. Avantages du Burndown chart
3. Inconvénients du Burndown chart
4. Sommaire

Introduction

Nous avons écrit sur ce que c'est, comment créer et interpréter un burndown chart dans des articles précédents. Aujourd'hui, nous allons nous concentrer sur les avantages et les inconvénients du burndown chart. Cependant, la plupart d'entre eux ne sont pas cachés dans le graphique simple lui-même. Ils sont plutôt liés aux façons d'utiliser le burndown chart pour motiver l'équipe de développement, car ils décrivent les résultats de leur travail et renforcent l'auto-organisation.

Avantages du Burndown chart

Le burn chart vous permet de visualiser l'avancement de votre projet. Sa lisibilité et sa simplicité le rendent si populaire. C'est pourquoi c'est une bonne idée que le Burn Chart ne soit pas seulement une métrique constamment mise à jour cachée dans un outil de gestion de projet numérique. Si possible, cela vaut la peine d'en faire un point de référence pour l'équipe de développement visible sur le lieu de travail physique. Que ce soit sous la forme d'une visualisation à l'écran ou d'un croquis dessiné à la main.

Cela motive l'équipe de développement

La transparence du burn chart peut en faire un outil pour motiver l'équipe de développement à travailler efficacement. Atteindre le point « zéro » à chaque Sprint peut devenir un objectif ambitieux de la Team, pour lequel des récompenses sont données – selon les principes de la gamification en entreprise.

La visibilité d'un tableau d'avancement à jour et maintenu de manière intéressante peut également renforcer un esprit de coopération et d'auto-organisation. Après tout, la métrique est une mesure du travail d'équipe. Il ne montre pas exactement qui a réalisé – ou non – les tâches planifiées, mais uniquement les résultats obtenus.

Il mesure le travail réel effectué

Les développeurs décident du nombre de tâches qu'ils effectueront dans un sprint donné. Plus l'équipe est expérimentée, plus elle doit prédire ses actions avec précision. Et le tableau de bord reflète la progression réelle du Sprint.

Ainsi, l'avantage du burn chart n'est pas tant de mesurer la quantité objective de travail effectué, mais le rapport entre les tâches planifiées et terminées. Ainsi, les Développeurs apprennent progressivement à les planifier et peuvent estimer de plus en plus précisément leurs capacités et éliminer les erreurs répétitives.

Il se couple avec d'autres outils

L'un des avantages significatifs du burndown chart concerne sa polyvalence en combinaison avec d'autres outils. Les outils suivants peuvent s'appliquer à :

• analyser le travail de l'équipe de développement
• visualiser l'avancement des travaux sur le Produit
• estimer le budget du projet

Par exemple, dans ce dernier cas, l'utilisation du tableau d'avancement de l'échelle du projet permet de comparer le budget prévu et réel pour l'ensemble du projet.

Inconvénients du Burndown chart

Malgré tous les avantages du graphique Burndown décrits ci-dessus, il peut devenir une source de confusion pour l'équipe de développement. Cependant, ce que nous appelons fréquemment les "défauts" du burndown chart ne sont pas dus aux imperfections de l'outil lui-même. Les problèmes décrits ci-dessous concernent la manière d'implémenter le burndown chart plutôt que sa conception. Vous trouverez ci-dessous les défauts qui peuvent interférer avec la représentation des progrès de l'équipe de développement de cette manière.

"Le facteur humain"

Les graphiques ne peuvent pas être une mesure absolue des progrès d'une équipe. Ce ne sont que des outils à appliquer de différentes manières, plus ou moins habiles. Nous pouvons le considérer comme un inconvénient (ou un avantage) non seulement du burndown chart mais aussi d'autres mesures de la performance de l'équipe.

Pour créer un graphique burndown, vous avez besoin d'autres personnes pour saisir les données. En d'autres termes, les développeurs inscrivent le temps d'achèvement des tâches sur le graphique. Ils l'ont peut-être un peu rallongé ou raccourci, soit par inattention, soit par désir d'améliorer les choses pour l'équipe. Les développeurs oublient aussi parfois de consigner leur temps. Ou laissez la minuterie allumée. Cela entraîne un allongement du temps de travail à plusieurs heures. Et après avoir découvert l'erreur, il est difficile de reconstituer son véritable parcours.

Modifications du backlog de sprint

Le Sprint Backlog ne doit pas être modifié après le début d'un Sprint. Cependant, dans la pratique, de tels changements se produisent assez souvent. Ils résultent de l'évolution des exigences des parties prenantes. Ou des problèmes imprévus rencontrés par les développeurs.

Cela entraîne la mise à l'échelle du graphique burndown. En effet, le temps nécessaire pour accomplir les tâches reste le même. Cependant, l'échelle des tâches restantes augmente. Cela peut donner l'impression trompeuse que l'équipe de développement a mal planifié le travail à faire dans un sprint donné. Ou que cela fonctionne trop lentement.

Les modifications apportées au Sprint Backlog peuvent également résulter de tâches planifiées pour s'achever trop rapidement. Dans une telle situation, l'équipe de développement décide généralement d'augmenter le nombre de tâches. Cela peut à son tour entraîner le fait de ne pas les terminer à temps. De plus, des conflits peuvent survenir en raison du chevauchement des tâches restantes du Sprint précédent avec de nouvelles tâches programmées pour être complétées par les parties prenantes et les Product Owners.

Modifications du carnet de produit

De grands changements dans le Product Backlog peuvent perturber la forme du burn chart. Et fausser ainsi fortement l'image de l'avancement du travail et de l'efficacité de l'équipe. Cela se produit lorsque de nouvelles User Stories apparaissent. Et ceux qui sont proches de la phase de mise en œuvre sont souvent divisés en parties plus petites. Il arrive également que le Client renonce à certaines fonctionnalités du Produit.

Par conséquent, lors de l'interprétation du burn chart, il faut être guidé par les connaissances et l'expérience dans l'évaluation de la performance de l'équipe. Et aussi prendre en compte la variabilité du Backlog. Si le graphique n'est pas la seule mesure utilisée pour évaluer les performances, les autres graphiques vous permettront d'avoir une image plus complète de l'avancement des travaux.

Sommaire

Le burndown chart peut contribuer de manière significative à la motivation de l'équipe de développement. C'est parce qu'il fournit une mesure du travail réel effectué sur le plan. De plus, sa combinaison avec d'autres outils métriques peut être une source de connaissances précieuses sur le travail de l'équipe et la planification du produit.

En appliquant soigneusement les principes Scrum, vous pouvez éviter les problèmes potentiels avec le burndown. La chose la plus importante est d'adapter les outils permettant de maintenir le graphique en fonction du travail réel de l'équipe Scrum, ainsi que de minimiser les modifications apportées au Sprint et au Product Backlog, dont nous parlerons plus en détail dans cet article.

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