La vélocité est une notion agile souvent mal comprise et mal utilisée. Elle est d’ailleurs source de stress auprès des équipes agiles.
Qu’est-ce que la vélocité agile exactement ? En quoi est-ce utile ? Comment faire pour calculer la vélocité de l’équipe ? Quels sont les pièges à éviter ? Et comment cela permet de planifier les futurs sprints ?
Réponse dans l’article.
Définition de la vélocité agile
La vélocité est un indicateur de mesure agile qui permet de déterminer la quantité de travail qu’est capable de fournir une équipe agile sur un sprint. L’indicateur de vélocité se calcule à chaque itération d’un projet agile, et correspond à la somme totale des points d’efforts des items réalisés à la fin du sprint.
La vélocité est un outil de macro-planification qui permet ainsi de faire des projections sur le nombre de sprints nécessaires afin de réaliser les user stories composant le product backlog. Il ne doit en aucun cas être utilisé pour planifier les tâches à réaliser pour le sprint, en sprint planning.
La vélocité d’une équipe n’est pas figée, elle évolue avec le temps.
Pour aller + loin : Je vous invite à consulter ces articles pour découvrir les différentes techniques d’estimation agile et pour approfondir le fonctionnement du planning poker.
Pourquoi la vélocité est-elle utile ?
- La vélocité est un outil de planification macro.
Elle permet à l’équipe de développement, au Product owner et au Scrum Master d’estimer le nombre d’itérations nécessaires pour aller au bout d’une fonctionnalité ou d’un projet. - La vélocité permet de donner une fenêtre de fin de projet.
Plus le calcul de la vélocité est fiable, plus vous êtes en mesure de réduire l’incertitude, et donc de réduire la taille de la fenêtre d’arrivée. - La vélocité permet de répondre à la question des parties prenantes : « Quand le projet sera t-il terminé ? ».
Cet outil permet ainsi de donner de la visibilité en terme de planning pour le client et les parties prenantes. Attention : il s’agit seulement d’une estimation, pas d’un engagement ferme et définitif. - La vélocité amène de la transparence.
Cet indicateur offre de la visibilité sur ce qui a été fait par l’équipe, et donne une estimation sur ce qui pourrait être fait.
Comment calculer la vélocité d’une équipe agile ?
Vous allez voir, calculer la vélocité d’une équipe agile est ultra simple. Pas besoin d’avoir fait Math Sup et de s’être tapé quelques années de calcul matriciel à la fac.
Prenons un exemple pour calculer la vélocité de l’équipe en fin de sprint.
A la fin d’un sprint de 2 semaines, voici l’état des différentes stories :
| User Stories | Points | État |
|---|---|---|
| Tâche 1 | 5 | Réalisée |
| Tâche 2 | 3 | Réalisée |
| Tâche 3 | 1 | Réalisée |
| Tâche 4 | 8 | Réalisée |
| Tâche 5 | 3 | Réalisée |
| Tâche 6 | 1 | En cours |
Afin de calculer la vélocité de ce sprint, nous allons faire la somme des points d’efforts des différentes tâches réalisées. Toutes les tâches qui ne sont pas terminées au sens de la definition of done ne doivent pas être prises en compte.
Dans notre cas, nous obtenons donc une vélocité de 5 + 3 + 1 + 8 + 3, soit une vélocité de 20 points.
Si l’on souhaite utiliser l’indicateur de vélocité a des fins de planification, il est alors nécessaire de réaliser une moyenne glissante sur les 5 à 8 dernières itérations de l’équipe.
| Itérations | Vélocité de fin de sprint |
|---|---|
| Sprint n°4 | 20 |
| Sprint n°5 | 17 |
| Sprint n°6 | 28 |
| Sprint n°7 | 13 |
| Sprint n°8 | 20 |
| Sprint n°9 | 14 |
Par exemple, si nous avons obtenu les vélocités dans le tableau ci-dessus sur les derniers sprints, notre vélocité moyenne sur les 5 derniers sprints sera donc de : (14 + 20 + 13 + 28 + 17) / 5 = 18,4.
Pour aller + loin : Je vous invite à consulter cet article pour éviter les pièges les plus courants concernant les story points.
Comment calculer la vélocité du premier sprint ?
Une question qui revient régulièrement est : comment calculer la vélocité du premier sprint.
Ce point chagrine régulièrement les équipes de développement, les Product Owner et les Scrum Master, alors que la réponse est pourtant assez simple.
Si vous avez suivi jusqu’ici, vous devriez même avoir la réponse.
Alors, comment calcule t-on la vélocité du premier sprint d’un projet agile ?
C’est simple : on ne le fait pas.
L’équipe de développement choisit les éléments à intégrer au sprint planning de cette première itération en fonction de ce qu’elle pense être capable de faire.Si en cours de sprint elle se rend compte qu’elle a avancé plus vite que prévu, elle peut alors décider d’ajouter des éléments dans le sprint courant.
La vélocité d’un sprint quant à elle ne peut se calculer qu’à la fin du sprint, à partir des éléments terminés.
Comment utiliser la vélocité agile ?
Maintenant que vous savez comment calculer la vélocité ainsi que la vélocité moyenne glissante pour une équipe agile, comment pouvez-vous faire pour exploiter ces chiffres ?
Déjà, je vous déconseille d’utiliser la vélocité pour planifier vos sprints. Ce n’est pas parce que la vélocité moyenne de l’équipe est à 20 points d’efforts par sprint que vous devez absolument vous débrouiller pour faire rentrer des user stories représentant 20 points d’efforts.
La vélocité est un outil de planification macro, il n’est ni destiné ni adapté à la planification détaillée.
Pour planifier de manière macro votre projet, vous pouvez :
- Calculer les points d’efforts nécessaires pour réaliser l’ensemble du périmètre du projet.
Cela correspond à la somme totale des points d’efforts de chacune des user stories se trouvant dans le product backlog. - Diviser cette somme par la vélocité moyenne glissante de l’équipe (sur les 5 derniers sprints minimum).
Vous obtenez alors le nombre de sprints restants pour aller au bout du projet, si la vélocité actuelle est maintenue. Si vous obtenez un nombre à virgule, vous pouvez l’arrondir au chiffre supérieur.
J’insiste sur un point : il s’agit là d’une estimation, que vous pouvez communiquer aux différentes parties prenantes du projet pour accroître leur visibilité, mais ce n’est absolument pas un engagement ferme et définitif de l’équipe.
L’équipe peut évoluer, les technologies utilisées également, les fonctionnalités demandées par le client également. Tous ces facteurs vont influencer la vélocité de l’équipe, c’est pour cela que celle-ci doit être prise pour ce qu’elle est : une estimation.
Les erreurs à ne pas faire avec la vélocité
Comme je l’ai dit dans l’introduction de l’article, la vélocité est un concept souvent mal compris et mal utilisé. Voici la liste des erreurs les plus courantes, que vous devriez absolument éviter, au risque de perdre en agilité dans votre équipe.
- Utiliser la vélocité pour faire la planification détaillée.
La vélocité est un indicateur permettant de faire des projections, ce n’est pas fait pour être utilisé afin de définir le périmètre d’un sprint ou de définir la capacité de travail de l’équipe. - Prendre la vélocité comme un engagement ferme et définitif.
La vélocité évolue au cours du temps. Ce n’est pas parce que l’équipe a réalisé 25 points d’efforts lors du dernier sprint qu’elle en fera autant sur le suivant. Cela dépendra des absences, des obstacles rencontrés, de la technologie employée, des connaissances apprises en cours de route, … - Arrêter de prendre des tâches dans le sprint en sprint planning car on a atteint la limite de vélocité.
La vélocité représente la capacité de travail passée de l’équipe, sur les 5 derniers sprints. Elle ne représente pas la capacité future de l’équipe. Si l’équipe de développement pense être en capacité de réaliser des tâches supplémentaires, elle doit prendre ces éléments dans le sprint backlog.
- Ne pas prendre assez d’historique pour calculer la vélocité moyenne.
Pour calculer la vélocité moyenne de l’équipe et réaliser des projections sur le nombre de sprints restants, il est nécessaire d’avoir un recul suffisant. On conseille de prendre les 5 à 8 dernières vélocités de sprint afin d’en calculer la moyenne. - Se lancer dans des calculs complexes.
Le calcul de la vélocité doit rester aussi simple que possible : une addition des points d’efforts réalisés sur le sprint, et une moyenne sur les 5 à 8 derniers sprints. Calculer une vélocité en fonction de la taille de l’équipe, des membres présents à un instant t, de la capacité de travail, de la dette technique, des absences, etc… est contre-productif. D’une part cela vous demandera du temps, d’autre part vous perdez en agilité et vous vous rapprochez des méthodes prédictives en agissant ainsi. - Calculer la vélocité en pourcentage.
Oui, je vous assure que je l’ai vu, le calcul était inutilement complexe, personne ne comprenait réellement ce que cela signifiait. En clair, c’est du vent, du brassage d’air, c’est tout ce que l’on veut, mais absolument pas de l’agilité. - Considérer uniquement les points d’efforts et la vélocité sans tenir compte du reste.
Parce qu’on a eu une vélocité de 25 points d’efforts lors du dernier sprint ne signifie pas qu’on doit remplir le sprint backlog de fonctionnalités représentant 25 points. S’il s’agit de 25 points de fonctionnalités « back-end » alors que vous ne disposez que d’un seul développeur back-end dans l’équipe, ce n’est pas tenable, ni réalisable. C’est à l’équipe de décider de ce qui doit rentrer ou non dans le sprint backlog, en fonction de ce qu’elle estime capable de réaliser. Cela tient forcément compte des absences et autres charges. - Prendre la vélocité comme un indicateur de performances.
La vélocité n’est pas un indicateur de performances. D’ailleurs, cet indicateur devrait idéalement rester dans les mains de l’équipe pour éviter de mauvaises interprétations des parties prenantes. Cela fluctue forcément au cours du temps : équipe qui grossit ou diminue, membres qui tournent, technologies qui évoluent, user stories de type différents à traiter, adhérences entre tâches, contraintes, etc… La baisse momentanée de la vélocité ne signifie pas que l’équipe a perdu en performance. - Comparer la vélocité de plusieurs équipes entre elles.
ça n’a pas de sens de comparer la vélocité de deux équipes différentes : trop de facteurs rentrent en jeu, les projets ne sont pas les mêmes, etc.. Comparer la progression de vélocité d’une même équipe ne fait pas forcément sens non plus. Les mêmes facteurs que ceux cités ci-dessus rentrent en ligne de compte. Le plus important, c’est que la vélocité soit relativement stable de sprint en sprint. Une vélocité qui chute durablement peut indiquer un problème dans l’équipe quand une vélocité qui monte durablement peut indiquer une baisse de la qualité et donc des livrables bâclés.
Un livre pour mieux estimer ses user stories
Pour découvrir en détails les concepts d’estimation et de planification agile, je vous conseille chaudement le livre « Agile estimating and planning » de Mike Cohn.
La vélocité est-elle une mesure utile ?
La vélocité est une mesure utile quand elle est bien utilisée, c’est à dire pour de la planification macro.
Tout autre usage comme la planification détaillée en sprint planning, ou la mesure de la performance de l’équipe n’est pas du tout adapté à l’indicateur de vélocité.
La vélocité de l’équipe va évoluer en cours de route, en fonction de nombreux facteurs : taille de l’équipe, rotation des membres, évolution des besoins client, difficultés techniques rencontrées, outils et technologies utilisés, …
Sur la durée, la vélocité de l’équipe doit être relativement stable. Si vous constatez une évolution en dents de scie, c’est plutôt contrariant. Il y a là un problème à creuser avec l’équipe, car ça veut dire qu’1 itération sur 2, l’équipe n’arrive pas à terminer ce sur quoi elle s’est engagée.
Pour aller + loin : Découvrez dans cet article quelles sont les différentes méthodes d’estimation agile, et dans celui-ci pourquoi les estimations jours/homme ne sont pas viables.
