Un graphique d’avancement 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 découvrir comment créer et interpréter un graphique d’avancement.

Comment créer et interpréter un graphique d’avancement ? – table des matières :

  1. Comment créer un graphique d’avancement ?
  2. Qui est responsable du graphique d’avancement ?
  3. Comment interpréter un graphique d’avancement ?
  4. Graphique d’avancement réel et idéal
  5. Sélection de l’unité de mesure
  6. Résumé

Comment créer un graphique d’avancement ?

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 éprouvés à cet effet est le graphique d’avancement.

Vous pouvez le créer manuellement en traçant 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, des points d’histoire. Sur l’axe X, dessinez une échelle indiquant les jours consécutifs du Sprint. Tracez une ligne du sprint idéal puis marquez le nombre de tâches réalistement complétées pour chaque jour. Bien que cette solution soit charmante et engage l’équipe, elle n’est pas très pratique. Elle n’est également pas nécessairement adaptée aux équipes distantes.

Par conséquent, les moyens numériques de créer un graphique d’avancement sont beaucoup plus courants. De nombreux outils pour enregistrer le travail sur les tâches réparties entre les membres de l’équipe proposent une option pour 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é de produit particulière, et sa contribution est reflétée dans le graphique d’avancement.

Avec les bons outils, il est également possible de redimensionner 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 à considérer lors du choix d’un outil pour créer un graphique d’avancement est son accessibilité à tous les membres de l’équipe Scrum. La visibilité du graphique d’avancement pour l’ensemble de l’équipe de développement est un facteur de motivation clé. Tout aussi important est un regard quotidien sur la ligne montrant le travail restant à faire. Parler de l’avancement lors du Daily Scrum amène les développeurs à réfléchir aux façons dont ils travaillent et à l’état actuel du produit.

Qui est responsable du graphique d’avancement ?

La question de la propriété du graphique d’avancement 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 selon le plan. D’autre part, il devrait rester entre les mains du Product Owner, car il reflète les progrès vers un objectif produit qui est communiqué au client. De plus, un tiers qui pourrait revendiquer sa propriété est l’équipe de développement, car le graphique fonctionne comme son outil interne.

Le graphique d’avancement est une métrique essentielle pour évaluer l’efficacité de l’équipe de développement et est 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 la motivation et donner une image réelle de l’état du travail sur les tâches qui lui sont assignées. Par conséquent, en théorie, chaque membre de l’équipe de développement peut mettre à jour le graphique d’avancement.

En pratique, cependant, la tâche de mise à jour du graphique d’avancement 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 graphique est censé être une mesure honnête et interne des progrès du travail jugée par les développeurs eux-mêmes.

graphique

Comment interpréter un graphique d’avancement ?

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

Graphique d’avancement réel et idéal

Pour interpréter un graphique d’avancement, le facteur clé n’est pas seulement le tracé régulier de la “combustion” réelle, c’est-à-dire l’exécution des tâches par l’équipe de développement. Tout aussi important pour l’image est sa comparaison avec la ligne de combustion idéale (ligne directrice).

En comparant la ligne de combustion idéale avec la réduction réelle du travail marquée sur le graphique d’avancement, deux paramètres très importants peuvent être évalués. D’abord, pour voir si le travail continue au rythme actuel, l’équipe de développement atteindra l’objectif du Sprint ou l’objectif produit à temps. Deuxièmement, pour avoir une idée de quand le travail sera terminé tout en maintenant le rythme actuel. En d’autres termes, le graphique d’avancement montre le rythme réel des tâches, et la ligne idéale montre à quel rythme l’équipe devrait travailler pour compléter les tâches.

Le graphique d’avancement permet également de déterminer une valeur appelée vélocité de l’équipe de développement à long terme. Nous lui consacrerons un article séparé. Ici, nous mentionnerons juste qu’il s’agit d’une valeur déterminée par la quantité de travail réalisée pendant un Sprint.

Grâce au fait que le graphique d’avancement illustre la comparaison d’une ligne de combustion idéale avec une réelle diminution du nombre de tâches, il permet de estimer le rythme de travail. Et ainsi anticiper le risque de retards dans le projet.

Sélection de l’unité de mesure

La vélocité de l’équipe est généralement mesurée en unités appelées points d’histoire. Elle définit le nombre d’histoires utilisateur qui ont été réalisées. Celles-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-homme. Chaque développeur estime puis enregistre le temps passé sur ses tâches.

Une autre option est de adopter les tâches comme 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 heures-homme. C’est une unité qui permet au client de présenter les progrès du travail sur le produit de manière plus claire.

Quelle que soit l’unité de mesure, il est bon de se rappeler le principe de calcul de la vitesse de l’équipe de développement. Dans un jour ou un Sprint donné, seules les tâches qui ont été réellement complétées comptent. Cela signifie que les tâches commencées seront comptées pour le jour ou le Sprint suivant même s’il ne manque que le test final.

Résumé

Comment créer et interpréter un graphique d'avancement ?

Avec les outils de surveillance d’équipe disponibles, créer 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é de abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Caroline Becker

En tant que chef de projet, Caroline est une 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 pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.

View all posts →

Scrum Guide:

  1. Glossaire des termes, rôles et notions de base
  2. Qu'est-ce que Scrum ?
  3. Valeurs Scrum
  4. Comment mettre en œuvre Scrum dans votre entreprise ?
  5. Équipe Scrum - qu'est-ce que c'est et comment ça fonctionne ?
  6. Qui est un Product Owner ?
  7. Les erreurs les plus courantes du Product Owner
  8. Qui est le Scrum Master ?
  9. Les erreurs les plus courantes des Scrum Masters
  10. Quelles statistiques et métriques le Scrum Master devrait-il suivre ?
  11. Équipe de développement en Scrum
  12. Les erreurs les plus courantes des développeurs
  13. Artifacts Scrum
  14. Élargir Scrum
  15. Backlog de sprint
  16. Qu'est-ce que le Product Backlog ?
  17. Qu'est-ce que les User Stories ?
  18. Créer la meilleure User Story avec INVEST
  19. Les erreurs les plus courantes dans les User Stories
  20. Critères d'acceptation de l'histoire utilisateur
  21. Estimation et Points d'Histoire dans Scrum
  22. Planning Poker
  23. Jeu d'estimation d'équipe
  24. Définir l'incrément
  25. Événements Scrum
  26. Qu'est-ce qu'un graphique d'avancement ?
  27. Avantages et inconvénients du graphique de burndown
  28. Tableaux Kanban dans Scrum et Scrumban
  29. Vélocité en Scrum - Vitesse de l'équipe de développement
  30. Scrum quotidien
  31. Planification de Sprint
  32. Revue de Sprint
  33. Qu'est-ce qu'une rétrospective de sprint ?
  34. Erreurs courantes lors d'une rétrospective de Sprint
  35. Nourrir le backlog produit
  36. Comment créer et interpréter un graphique de burndown ?
  37. Qu'est-ce qu'un Sprint dans Scrum ?
  38. Coopération entre le Product Owner et le Scrum Master
  39. Engagements de l'équipe Scrum - Objectif produit, objectif de sprint et définition de la complétion
  40. Caractéristiques d'un bon Scrum Master