Guide de mêlée | 34. Vélocité dans Scrum - Vitesse de l'équipe de développement

Velocity in Scrum vous aide à déterminer la vitesse à laquelle l'équipe Scrum termine les tâches. Nous pouvons le définir comme le nombre moyen de Story Points complétés dans un Sprint. Velocity peut également estimer la durée d'un projet en fonction de l'avancement des travaux déjà réalisés. Cependant, cela n'a de sens que pour une équipe mature qui travaille à un rythme régulier et régulier. Découvrez ce qu'est Velocity et comment l'optimiser pour vous !

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

1. Vélocité en Scrum – Introduction
2. Vitesse réelle et planifiée
3. Difficultés et risques associés à Velocity en Scrum
4. Sommaire

Vélocité en Scrum – Introduction

La vélocité est une méthode facultative mais populaire pour mesurer le rythme d'une équipe Scrum. En effet, une vélocité estimée avec précision permet de prédire, dans une mesure raisonnable, le temps nécessaire à la réalisation d'un projet. Cependant, il s'agit d'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 « valorisées » à l'aide d'une unité familière, comme les Story Points, 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 X sont marqués les Sprints consécutifs. Sur l'axe Y, en revanche, nous trouverons le nombre de Story Points ou d'autres unités correspondantes qui ont été complétées dans un Sprint donné. Avec le Velocity Chart, l'équipe Scrum obtient une vision claire des changements dans le rythme de son travail. Si la ligne marquée sur le graphique est en hausse, cela signifie que l'équipe optimise son efficacité ou réduit la valeur des Story Points. Le Scrum Master et le Product Owner doivent donc suivre attentivement la ligne indiquant la vélocité de l'équipe.

Vitesse réelle et planifiée

La vélocité réelle de l'équipe de développement décrit le rythme de travail dans le sprint terminé et est calculée à la fin de chaque sprint. Il prend la valeur de la somme des Story Points pour toutes les User Stories terminées. La vitesse 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 vitesse planifiée, quant à elle, est estimée sur la base d'une valeur moyenne de la vitesse réelle. Cela nécessite l'hypothèse d'aucun changement dans l'équipe de développement. Il s'agit d'un outil interne important pour l'équipe de développement qui, sur la base de celui-ci, peut évaluer si la coopération au sein de l'équipe se déroule bien et si le rythme de travail est maintenu.

Planned Velocity permet également au Product Owner de prévoir le temps d'exécution de User Stories bien définies dont l'exécution est prévue dans les Sprints suivants. Cela permet de nourrir plus efficacement le Product Backlog, dont nous avons parlé dans cet article. Cependant, la pratique consistant à appliquer la vitesse planifiée pour estimer la durée des projets n'est pas si simple.

Difficultés et risques associés à Velocity en Scrum

On accorde souvent trop d'importance à la vélocité dans Scrum sans tenir compte des facteurs suivants :

• estimer des ensembles plus grands ou l'ensemble du projet - alors que l'équipe de développement peut estimer avec précision le nombre de points d'histoire à attribuer à une tâche spécifique, il est très difficile, voire 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 Story Points nécessaires pour atteindre l'objectif du produit. Il se peut également que des tâches déjà réalisées devront être modifiées voire ne pas être utilisées dans la version finale du Produit
• événements imprévus - prévoir le rythme des projets futurs en fonction de ceux déjà achevés, c'est-à-dire traduire la vitesse réelle en vitesse planifiée, 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.

Sommaire

L'utilisation de Velocity 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 avec plus de précision.

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. En effet, cela lui permet de déterminer le nombre de tâches qu'il est capable d'accomplir au cours d'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 Velocity comme métrique pour évaluer l'équipe de développement. En effet, cela peut conduire à 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é 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