Guide de mêlée | 11. Statistiques et métriques que le Scrum Master doit suivre

Pourquoi le Scrum Master a-t-il besoin de statistiques et de métriques ? Premièrement, pour vérifier si ses méthodes de travail sur la prévisibilité des résultats et l'amélioration de l'efficacité de l'équipe sont efficaces. Mais aussi pour garder une trace de la façon dont leurs actions affectent l'équipe de développement. Autrement dit, comment ils façonnent l'expérience utilisateur des employés (UX). Ainsi, dans cet article, nous introduisons des statistiques et des métriques que le Scrum Master doit suivre.

Statistiques et métriques importantes pour le scrum master – table des matières :

1. Mesurer les résultats du travail de l'équipe de développement
2. Suivi de l'expérience utilisateur des collaborateurs Développeurs
3. Sommaire

Mesurer les résultats du travail de l'équipe de développement

Les statistiques et métriques les plus couramment utilisées que le Scrum Master doit suivre sont celles qui décrivent le rythme et le flux d'exécution des tâches. Il s'agit du Burnup Chart, du Burnup Chart et du Cumulative Flow Chart. Ceux-ci mesurent à la fois le développement du produit et l'efficacité de l'équipe. Chacune vous permet d'aborder ces questions sous un angle différent, il est donc judicieux de les montrer ensemble. Ce sont des outils pratiques pour évaluer les progrès à différentes échelles, pendant un Sprint ainsi que tout le processus de développement de produit.

Tableau de combustion

Le burndown chart montre au Scrum Master et à l'équipe de développement combien de travail a été fait et combien il reste à faire. L'axe X indique le temps restant pour terminer le travail. L'axe Y montre la quantité de travail restant à faire qui était prévue dans le Sprint Backlog ou le Product Backlog.

Ce tableau permet également de déterminer la vitesse de l'équipe de développement, à laquelle nous consacrerons également un article séparé. Ici, nous mentionnerons seulement qu'il s'agit d'une quantité moyenne de travail effectuée au cours d'un Sprint.

Cet outil simple permet au Scrum Master non seulement de voir à quel point l'équipe travaille efficacement. Il permet également de répondre aux questions :

• Quelle partie des travaux a déjà été réalisée ?
• Combien de tâches reste-t-il à accomplir ?
• Combien de temps faudra-t-il pour développer le produit ?

Lors de l'utilisation du Burndown Chart, le Scrum Master doit garder à l'esprit que ce n'est pas le seul outil pour évaluer statistiquement les progrès de l'équipe. Cela fonctionne mieux pour les projets où la portée des travaux est fixe et connue. Il ne fonctionne pas bien avec la création de solutions très innovantes avec un nouveau Client. Ensuite, la quantité de travail à effectuer dans l'ensemble du projet - c'est-à-dire le contenu du Product Backlog - peut changer de manière significative au cours du projet, ce qui rend difficile l'utilisation du Burndown Chart.

Graphique de combustion

Le graphique Burnup est l'inverse du graphique Burndown décrit ci-dessus. Ici aussi, l'axe Y montre la quantité de travail restant à faire. L'axe X, quant à lui, montre le temps de réalisation exprimé soit en nombre de Sprints, soit en dates.

Cependant, le Scrum Master utilise Burnup Chart dans un but légèrement différent. En effet, cela ne vous aide pas seulement à mesurer les progrès du produit et les progrès de l'équipe. Cette mesure évalue également la façon dont la portée des travaux d'un projet évolue au fil du temps. Par conséquent, cela fonctionne bien pour les projets à portée variable.

Le Burnup Chart est également un outil de planification qui devient de plus en plus efficace au fil du temps. Il fournit des réponses à la question de savoir combien de travail l'équipe de développement est censée faire dans le prochain Sprint.

Diagramme de flux cumulé

Le troisième type de diagramme qui est très fructueux dans le travail du Scrum Master avec l'équipe de développement est le diagramme de flux cumulé. Il présente l'analyse de la stabilité du rythme et de la productivité de l'équipe de développement. La disposition de ses axes est la même que celle du Burnup Chart, il est donc souvent appelé sa version la plus complexe.

Cependant, le diagramme de flux cumulatif ne sert pas seulement à déterminer le nombre de tâches terminées dans une période de temps donnée. Il prend également en compte le nombre de tâches en attente d'exécution dans la file d'attente. Grâce à cela, il permet de diagnostiquer les soi-disant « goulots d'étranglement » - moments du processus qui ralentissent la création d'un produit.

Cette fonctionnalité très diagnostique en fait l' une des métriques les plus utiles entre les mains du Scrum Master. En effet, cela permet de réorganiser le travail de manière à répartir différemment la force de l'équipe de développement et à éviter les temps d'arrêt.

Suivi de l'expérience utilisateur des collaborateurs Développeurs

La maintenance et l'analyse régulières et méticuleuses des statistiques sont une partie essentielle du travail d'un Scrum Master efficace. Cependant, il doit d'abord garder à l'esprit l'expérience utilisateur des développeurs, c'est-à-dire la façon dont ils perçoivent le travail dans l'équipe Scrum. Cependant, ce n'est pas la qualité des métriques qui décide, mais la manière dont le Scrum Master les utilise.

Si les statistiques sont conservées conformément aux principes de Scrum - elles sont transparentes, publiques et compréhensibles pour les développeurs impliqués - elles peuvent être un moyen de motiver l'équipe à travailler plus efficacement ou de les récompenser pour d'excellents résultats. Cependant, les statistiques peuvent fonctionner comme un outil pour faire pression sur l'équipe de développement. Leurs indications deviennent alors génératrices d'accusations et de ressentiments. Ils peuvent contribuer à détériorer le moral de l'équipe et à gâcher les pratiques de travail d'équipe.

Le deuxième facteur important de l'expérience employé des Développeurs, dont le Scrum Master travaillant avec des outils statistiques doit s'occuper, est la manière de gérer son temps. En effet, le Scrum Master doit disposer de suffisamment de temps pour s'occuper de l'équipe de développement. Pour cette raison, dans le cas d'un grand projet, il vaut la peine d'envisager d'inclure une personne supplémentaire dans l'équipe Scrum. Il agira en tant que chef de projet et s'occupera des métriques. Grâce à cela, il soulagera le Scrum Master – et dans une certaine mesure le Product Owner – des tâches qui le distraient du travail avec l'équipe de développement.

Statistiques et métriques – résumé

Le Scrum Master doit suivre les statistiques de base décrivant le travail de l'équipe de développement. Leur interprétation habile augmente les chances de repérer rapidement les problèmes dans le travail de l'équipe et d'y réagir. Cependant, ce que le Scrum Master en fait est plus important que de conserver les graphiques. Ils ne doivent pas traiter les métriques comme un outil pour évaluer l'équipe, mais plutôt comme une aide utile pour motiver l'équipe et diagnostiquer leur propre façon de faire les choses. En effet, les métriques ne seront des outils utiles que si elles contribuent à faciliter les processus d'amélioration de l'équipe et du produit.

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

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