Guide Scrum | 11. Statistiques et métriques que le Scrum Master devrait suivre

Pourquoi le Scrum Master a-t-il besoin de statistiques et de métriques ? Tout d’abord, 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 suivre comment leurs actions affectent l’équipe de développement. C’est-à-dire, comment elles façonnent l’expérience utilisateur (UX) des employés. Dans cet article, nous présentons les statistiques et les métriques que le Scrum Master devrait 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. Surveiller l’expérience utilisateur des développeurs
3. Résumé

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 devrait suivre sont celles qui décrivent le rythme et le flux de l’exécution des tâches. Ce sont le Burnup Chart, le Burnup Chart, et le Cumulative Flow Chart. Ces mesures évaluent à la fois le développement du produit et l’efficacité de l’équipe. Chacune 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 sur l’ensemble du processus de développement du produit.

Burndown Chart

Le burndown chart montre au Scrum Master et à l’équipe de développement combien de travail a été effectué et combien reste à faire. L’axe X montre 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 graphique aussi aide à 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 pendant un Sprint.

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

• Quelle partie du travail a déjà été complétée ?
• Combien de tâches restent à 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. Il fonctionne mieux pour les projets où l’étendue du travail est fixe et connue. Il ne fonctionne pas bien pour la création de solutions très innovantes avec un nouveau client. Dans ce cas, la quantité de travail à réaliser dans l’ensemble du projet – c’est-à-dire le contenu du Product Backlog – peut changer considérablement pendant le projet, rendant difficile l’utilisation du Burndown Chart.

Burnup chart

Le Burnup Chart est l’inverse du Burndown chart discuté ci-dessus. Ici aussi, l’axe Y montre la quantité de travail restant à faire. L’axe X, en revanche, montre le temps d’achèvement exprimé soit en nombre de Sprints, soit en dates.

Cependant, le Scrum Master utilise le Burnup Chart pour un but légèrement différent. Cela est dû au fait qu’il aide non seulement à mesurer les progrès du produit et les progrès de l’équipe. Cette métrique évalue également comment l’étendue du travail dans un projet change au fil du temps. Par conséquent, il fonctionne bien pour les projets à portée variable.

Le Burnup Chart est également un outil de planification qui devient plus efficace avec le temps. Il fournit des réponses à la question de combien de travail l’équipe de développement est estimée à faire dans le prochain Sprint.

Cumulative Flow Diagram

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 Cumulative Flow Diagram. 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 considéré comme sa version plus complexe.

Cependant, le Cumulative Flow Diagram ne sert pas seulement à déterminer le nombre de tâches complétées dans une période donnée. Il prend également en compte le nombre de tâches qui attendent dans la file d’attente pour exécution. 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 caractéristique diagnostique en fait l’une des métriques les plus utiles entre les mains du Scrum Master. Cela est dû au fait qu’il 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.

Surveiller l’expérience utilisateur des développeurs

Un entretien et une analyse réguliers et minutieux des statistiques sont une partie essentielle du travail efficace d’un Scrum Master. Cependant, il/elle doit garder à l’esprit d’abord l’expérience utilisateur des employés 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 tenues 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 de bons résultats. Cependant, les statistiques peuvent fonctionner comme un outil pour mettre la pression sur l’équipe de développement. Dans ce cas, leurs indications deviennent un générateur d’accusations et de ressentiments. Elles peuvent contribuer à détériorer le moral de l’équipe et à gâcher les pratiques de travail en équipe.

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

Statistiques et métriques – résumé

Le Scrum Master devrait suivre les statistiques de base décrivant le travail de l’équipe de développement. Leur interprétation habile augmente la chance de repérer rapidement les problèmes dans le travail de l’équipe et d’y réagir. Cependant, plus important que de garder les graphiques est ce que le Scrum Master en fait. Il ne devrait pas considérer les métriques comme un outil pour évaluer l’équipe, mais plutôt les traiter comme une aide utile pour motiver l’équipe et diagnostiquer leur propre façon de faire. Cela est dû au fait que les métriques ne seront utiles que si elles aident à faciliter les processus d’amélioration de l’équipe et du produit.

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