Guide Scrum | 34. Vitesse dans Scrum – Vitesse de l’équipe de développement

La vélocité dans Scrum vous aide à déterminer le rythme auquel l’équipe Scrum termine les tâches. Nous pouvons la définir comme le nombre moyen de points d’histoire complétés en un sprint. La vélocité peut également estimer la durée d’un projet en fonction des progrès réalisés. Cependant, cela n’a de sens que pour une équipe mature qui travaille à un rythme régulier et constant. Jetez un œil à ce qu’est la vélocité et comment la faire fonctionner au mieux pour vous !

Vélocité dans Scrum – table des matières :

1. Vélocité dans Scrum – Introduction
2. Vélocité réelle et prévue
3. Difficultés et risques associés à la vélocité dans Scrum
4. Résumé

Vélocité dans Scrum – Introduction

La vélocité est une méthode optionnelle mais populaire pour mesurer le rythme d’une équipe Scrum. Cela est dû au fait que une vélocité estimée avec précision permet de prédire, dans une certaine mesure, le temps nécessaire pour terminer un projet. Cependant, c’est une mesure qui ne peut être appliquée qu’à une équipe de développement donnée, qui effectuera des tâches qu’elle a elle-même “évaluées” en utilisant une unité familière, comme les points d’histoire, par exemple.

La vélocité de l’équipe de développement est le plus souvent présentée sous la forme d’un graphique de vélocité. Sur l’axe des X sont marqués des sprints consécutifs. Sur l’axe des Y, en revanche, nous trouverons le nombre de points d’histoire ou d’autres unités correspondantes qui ont été complétées dans un sprint donné. Avec le graphique de vélocité, l’équipe Scrum obtient une vue claire des changements dans le rythme de son travail. Si la ligne marquée sur le graphique est ascendante, cela signifie que l’équipe optimise son efficacité ou réduit la valeur des points d’histoire. Le Scrum Master et le Product Owner doivent donc suivre attentivement la ligne montrant la vélocité de l’équipe.

Vélocité réelle et prévue

La vélocité réelle de l’équipe de développement décrit le rythme de travail dans le sprint complété et est calculée à la fin de chaque sprint. Elle prend la valeur de la somme des points d’histoire pour toutes les user stories complétées. La vélocité réelle de l’équipe de développement vous permet de planifier et d’estimer avec une certaine probabilité le rythme des tâches futures.

La vélocité prévue, en revanche, est estimée sur la base d’une valeur moyenne de la vélocité réelle. Elle nécessite l’hypothèse qu’il n’y a pas de changement dans l’équipe de développement. C’est un outil interne important pour l’équipe de développement, qui, sur cette base, peut évaluer si la coopération au sein de l’équipe se déroule bien et si le rythme de travail est maintenu.

La vélocité prévue permet également au Product Owner de prévoir le temps d’exécution des user stories bien définies programmées pour exécution dans les sprints suivants. Cela permet un nurturing plus efficace du backlog produit, dont nous avons parlé dans cet article. Cependant, la pratique d’appliquer la vélocité prévue pour estimer les durées de projet n’est pas si simple.

Difficultés et risques associés à la vélocité dans Scrum

La vélocité dans Scrum est souvent trop mise en avant sans tenir compte des facteurs suivants :

• estimer des ensembles plus grands ou l’ensemble du projet – bien que l’équipe de développement puisse estimer avec précision le nombre de points d’histoire à attribuer à une tâche spécifique, il est très difficile ou impossible de décrire des ensembles plus grands pour une mise en œuvre future dans ces unités
• changements dans le projet – tout changement dans le projet signifie potentiellement un changement dans le nombre de points d’histoire nécessaires pour atteindre l’objectif produit. Il se peut également que des tâches déjà complétées doivent être modifiées ou même ne pas être utilisées dans la version finale du produit
• événements imprévus – prédire le rythme des projets futurs sur la base de ceux déjà complétés, c’est-à-dire traduire la vélocité réelle en vélocité prévue, peut aboutir à des estimations précises. Cependant, chaque projet a ses particularités et une prédiction précise basée sur l’historique est généralement impossible.

Résumé

Utiliser la vélocité comme métrique pour évaluer l’efficacité de l’équipe de développement peut entraîner une dégradation de sa fiabilité. Cela peut également dégrader la qualité des estimations, dont nous avons parlé plus en détail dans cet article. Après tout, pour obtenir les meilleurs résultats possibles dans les métriques, l’équipe de développement peut surestimer l’intensité de travail des tâches pour augmenter la vélocité. Cela est préjudiciable car l’équipe elle-même perd alors des informations précieuses pour apporter des améliorations et planifier ses tâches plus précisément.

La vélocité dans Scrum est principalement utile en tant que mesure interne utilisée par l’équipe de développement pour évaluer le rythme de son travail. Cela lui permet de déterminer combien de tâches elle est capable de compléter pendant un seul sprint.

La vélocité entre les mains du Product Owner devient un outil utile pour estimer le délai pour des tâches plus importantes.

Cependant, les plus grands risques sont associés à l’utilisation de la vélocité comme métrique pour évaluer l’équipe de développement. Cela peut entraîner une baisse de sa crédibilité et même une surestimation délibérée de sa valeur pour améliorer l’évaluation externe du travail de l’équipe Scrum.

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