Au début de chaque sprint, la même question revient dans toutes les équipes Scrum : combien de travail peut-on prendre cette fois ? La vélocité est la réponse habituelle, et aussi l'un des chiffres les plus mal utilisés de l'agilité.
La vélocité fait le lien entre l'estimation et la planification : elle transforme les story points de vos sessions d'estimation en un chiffre que l'équipe utilise pendant le sprint planning. Ce guide montre comment la calculer sur un exemple chiffré, comment s'en servir pour prévoir une release et quelles habitudes la vident de son sens.
Qu'est-ce que la vélocité en Scrum ?
La vélocité est la quantité de travail qu'une équipe Scrum termine en un sprint, généralement mesurée en story points. Pour la calculer, on additionne les estimations des éléments du backlog terminés selon la Definition of Done ; un élément inachevé compte pour zéro, sans crédit partiel. Un sprint isolé ne dit pas grand-chose : les équipes font la moyenne des trois à cinq derniers sprints, souvent en moyenne glissante, qui écarte à chaque fois le sprint le plus ancien. La vélocité est un outil de planification : elle aide l'équipe à dimensionner le prochain sprint, et le Product Owner à prévoir une release en fourchette de sprints plutôt qu'en date unique. Elle est propre à chaque équipe, puisque chacune étalonne ses story points : elle ne sert ni à comparer des équipes, ni à mesurer la productivité individuelle. Le Scrum Guide ne la mentionne jamais : il demande seulement aux Developers de s'appuyer sur leur performance passée et leur capacité à venir pour prévoir un sprint.
Comment calculer la vélocité d'un sprint ?
Le calcul tient sur un post-it. Ce sont les règles autour qui rendent le chiffre fiable.
- Lister ce qui est terminé. À la fin du sprint, on ne garde que les éléments qui respectent la Definition of Done, le standard commun que le Scrum Guide utilise pour dire quand un travail est fini.
- Additionner leurs estimations. Si l'équipe a terminé des stories à 5, 8, 3 et 5 points, sa vélocité pour ce sprint est de 21. Le guide d'Atlassian sur la vélocité applique la même méthode.
- Ignorer tout le reste. Une story finie à 90 % compte pour zéro. Mike Cohn est clair : une story inachevée en fin de sprint ne rapporte aucun crédit partiel à la vélocité (source). Elle compte en entier dans le sprint où elle est terminée, et la moyenne s'équilibre.
- Garder les estimations d'origine. Ne réestimez pas une story après coup parce qu'elle s'est révélée plus dure. La vélocité fonctionne parce que les estimations se trompent de la même manière d'un sprint à l'autre.
- Faire la moyenne sur plusieurs sprints. Un sprint, c'est du bruit. Trois à cinq sprints donnent une base exploitable.
À quoi ressemble un calcul de vélocité sur cinq sprints ?
Voici une équipe fictive de cinq développeurs, en sprints de deux semaines. « Prévus » désigne les points retenus au sprint planning, « terminés » la vélocité.
| Sprint | Points prévus | Points terminés (vélocité) | Moyenne glissante sur 3 sprints |
|---|---|---|---|
| 1 | 30 | 24 | Pas assez de données |
| 2 | 28 | 30 | Pas assez de données |
| 3 | 30 | 22 | 25,3 |
| 4 | 26 | 28 | 26,7 |
| 5 | 28 | 26 | 25,3 |
Les mêmes données se lisent de trois façons :
- Moyenne simple sur cinq sprints : (24 + 30 + 22 + 28 + 26) ÷ 5 = 26 points.
- Moyenne glissante sur les trois derniers sprints : (22 + 28 + 26) ÷ 3 ≈ 25,3 points. Chaque nouveau sprint chasse le plus ancien : le chiffre suit les vrais changements de l'équipe sans surréagir à un sprint isolé.
- Fourchette : l'équipe a terminé entre 22 et 30 points par sprint. Cet écart est normal : selon Mike Cohn, la vélocité varie d'environ 20 % en plus ou en moins d'un sprint à l'autre (source).
Pour le sprint 6, cette équipe devrait viser 25 ou 26 points, pas 30. Planifier sur le meilleur sprint, c'est reporter du travail presque à chaque fois. L'écart entre points prévus et terminés mérite aussi l'attention : quand une équipe termine régulièrement moins que prévu, le problème vient de la planification, pas des développeurs.
Pourquoi trois à cinq sprints ? En dessous, un sprint atypique écrase la moyenne ; bien au-delà, elle décrit une équipe qui n'existe plus. Une équipe toute neuve n'a pas encore de vélocité : elle planifie à partir de sa capacité, décrite plus bas, et commence à mesurer.
Quelle différence entre vélocité et capacité ?
La vélocité regarde en arrière : c'est ce que l'équipe a terminé. La capacité regarde devant : c'est le temps dont l'équipe dispose vraiment au prochain sprint, une fois retirés congés, jours fériés, formations et astreintes. Le Scrum Guide les met côte à côte : plus les Developers connaissent leur performance passée, leur capacité à venir et leur Definition of Done, plus ils ont confiance dans leurs prévisions de sprint.
| Vélocité | Capacité | |
|---|---|---|
| Regarde | Le passé : ce qui a été terminé | L'avenir : le temps disponible |
| Unité | Story points par sprint | Jours-homme ou heures |
| Source | Éléments terminés des derniers sprints | Le calendrier de l'équipe pour le prochain sprint |
| Usage principal | Prévoir une release sur plusieurs sprints | Ajuster le plan du prochain sprint |
| Change quand | L'équipe, l'échelle ou la Definition of Done change | Quelqu'un est en congé, un jour férié tombe dans le sprint |
Les deux se combinent naturellement. Mike Cohn propose d'ajuster la vélocité moyenne au nombre de jours travaillés : vélocité prévue = vélocité moyenne × (jours travaillés prévus ÷ jours travaillés habituels) (source). Notre équipe dispose d'habitude de 50 jours travaillés par sprint (5 personnes × 10 jours). Si le sprint 6 contient un jour férié et une semaine de congés, on tombe à 40 jours : 26 × 40 ÷ 50 ≈ 21 points.
Pour le sprint lui-même, Cohn va plus loin. La vélocité varie trop pour être utile à court terme, explique-t-il : il préfère un sprint planning piloté par la capacité. L'équipe prend les éléments un par un, les découpe en tâches, s'arrête quand le sprint lui paraît plein, puis compare le total à sa vélocité. Pour lui, la vélocité est utile à long terme, pas à court terme : son vrai rôle, c'est la planification de release.
Comment prévoir une release avec la vélocité ?
C'est en prévision que la vélocité montre tout son intérêt, à condition de donner une fourchette. Le guide de prévision de Mountain Goat Software le résume : une moyenne unique a l'air précise, mais elle masque la variabilité normale d'une équipe. Il décrit deux calculs, un par question.
Périmètre fixe : quand sera-t-on prêt ? On divise le travail restant par le haut et le bas de la fourchette de vélocité. Il reste 160 points dans la release de notre équipe :
- au mieux : 160 ÷ 30 ≈ 5,3, donc 6 sprints ;
- au pire : 160 ÷ 22 ≈ 7,3, donc 8 sprints.
En sprints de deux semaines, la prévision devient « entre 12 et 16 semaines », pas « dans 6,2 sprints ».
Date fixe : qu'est-ce qui sera prêt ? On multiplie le nombre de sprints restants par chaque borne de la fourchette. Avec 5 sprints avant un salon : 5 × 22 = 110 points et 5 × 30 = 150 points. Le Product Owner peut annoncer que les 110 premiers points du backlog ordonné sont très probables, que les 40 suivants sont possibles et que rien au-delà de 150 ne sera prêt.
Présentez la fourchette avec ses hypothèses (même équipe, même échelle, périmètre actuel) et mettez-la à jour à chaque sprint : pour Mountain Goat Software, une prévision n'est pas un engagement. Pour une fourchette statistique, leur Velocity Range Calculator, gratuit, demande au moins cinq vélocités passées. Pour traduire la fourchette de sprints en jours-homme et en budget, voyez notre comparatif story points vs jours-homme.
Qu'est-ce qui fait varier la vélocité ?
Une variation de vélocité est une question, pas un verdict. Les causes habituelles :
- Changements dans l'équipe. Un nouvel arrivant ralentit l'équipe quelques sprints ; un départ retire de la capacité et du savoir.
- Disponibilité. Congés, formations et astreintes réduisent la capacité : ajustez le plan comme vu plus haut.
- Travail imprévu. Incidents, bugs urgents et demandes de support grignotent le sprint. S'ils reviennent à chaque sprint, réservez-leur une part de la capacité.
- Dette technique et dépendances. Un code fragile et l'attente d'autres équipes ralentissent chaque story ; Atlassian cite la complexité et les dépendances parmi les facteurs qui font bouger la vélocité.
- Changements de process. Une nouvelle Definition of Done, une autre durée de sprint ou une autre échelle changent la valeur d'un point : repartez d'une nouvelle base.
- Dérive des estimations. Sans stories de référence stables, les estimations gonflent peu à peu, et la vélocité monte alors que la production réelle ne bouge pas.
Une hausse lente sur plusieurs mois signifie le plus souvent que l'équipe progresse vraiment. Un bond soudain et inexpliqué trahit plutôt des estimations qui gonflent.
Quelles sont les erreurs les plus courantes avec la vélocité ?
La plupart des problèmes viennent d'un usage pour lequel la vélocité n'a pas été conçue.
| Mauvaise pratique | Ce qui se passe | À faire plutôt |
|---|---|---|
| Vélocité comme objectif ou KPI | Les estimations gonflent pour atteindre le chiffre | Réserver la vélocité à la planification |
| Comparer des équipes | Chaque équipe a son échelle, le classement ne veut rien dire | Comparer une équipe à ses propres sprints passés |
| Convertir les points en heures | L'estimation dépend de nouveau de qui fait le travail | Convertir au niveau de l'équipe, par la vélocité et la capacité |
| Compter des stories à moitié faites | La vélocité paraît plus haute que le travail réellement fini | Ne compter que le terminé |
| Planifier sur le meilleur sprint | Du travail reporté presque à chaque sprint | Planifier sur la moyenne, ou un peu en dessous |
| Mesurer les individus | Chacun optimise ses points au détriment de l'équipe | Garder la vélocité comme mesure d'équipe |
La vélocité comme objectif. Dès qu'on demande « plus de points au prochain sprint », le plus simple pour obéir est d'estimer plus haut. C'est la loi de Goodhart, souvent citée dans la formulation de Marilyn Strathern : lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure. Ron Jeffries ajoute qu'augmenter la pression pour en faire plus finit presque toujours mal.
Comparer des équipes. Ron Jeffries juge néfaste de comparer des équipes sur leur vélocité (source). Atlassian fait le même constat par l'autre bout : chaque équipe estimant sur sa propre échelle, impossible de brandir la vélocité comme une arme (source). Une équipe à 40 points n'est pas deux fois plus productive qu'une équipe à 20.
Convertir en heures. « Un point = quatre heures » transforme la vélocité en feuille de temps, alors que les heures derrière un point varient d'une personne à l'autre : voyez ce qu'est un story point.
Quel lien entre story points, Planning Poker et vélocité ?
La vélocité n'est jamais plus cohérente que les estimations qui la composent. Si le même type de story vaut 3 une semaine et 8 la suivante, la somme ne veut plus dire grand-chose. Trois habitudes stabilisent les estimations, et donc la vélocité.
- Estimer en équipe, en même temps. Le Planning Poker fait voter chaque développeur en secret avant une révélation commune : l'ancrage recule et toute l'équipe porte l'estimation.
- Garder la même échelle et les mêmes stories de référence. Une échelle de Fibonacci et deux ou trois stories de référence gardent au 5 le même sens pendant des mois.
- Utiliser des valeurs qui s'additionnent. La vélocité est une somme : il lui faut des nombres. Les tailles T-shirt ne nourrissent une vélocité qu'une fois chaque taille associée à un nombre de points.
Quel que soit votre outil (notre comparatif des outils de Planning Poker gratuits présente les principaux), reportez les estimations votées dans votre outil de backlog pour que la vélocité soit calculée sur elles. Notre guide pour animer une session de Planning Poker couvre l'animation.
Questions fréquentes
Comment calculer la vélocité d'une équipe Scrum ? Pour calculer la vélocité d'une équipe Scrum, on additionne les story points de tous les éléments du backlog qui respectent la Definition of Done à la fin du sprint. Les éléments inachevés comptent pour zéro. On fait ensuite la moyenne des trois à cinq derniers sprints, et on exprime la prévision sous forme de fourchette.
Qu'est-ce qu'une bonne vélocité ? Il n'existe pas de bonne vélocité dans l'absolu. La vélocité dépend de l'échelle de story points propre à l'équipe, de sa taille et de la durée de ses sprints : 20 points peuvent être beaucoup pour une équipe et peu pour une autre. Une bonne vélocité est une vélocité stable, qui permet de planifier et de prévoir.
Faut-il compter les bugs dans la vélocité ? Les bugs peuvent compter dans la vélocité si l'équipe les estime en story points comme les autres éléments du backlog. Beaucoup d'équipes préfèrent ne pas les estimer et leur réserver une part de la capacité de chaque sprint. Les deux approches fonctionnent, à condition d'en choisir une et de s'y tenir dans la durée.
Vélocité et capacité, est-ce la même chose ? Non. La vélocité mesure le travail qu'une équipe a terminé lors des sprints passés, en général en story points. La capacité mesure le temps dont l'équipe dispose au prochain sprint, en jours-homme ou en heures, congés et jours fériés déduits. On utilise la capacité pour ajuster la vélocité moyenne avant de planifier.
Combien de sprints faut-il pour mesurer la vélocité ? Trois sprints donnent une première vélocité exploitable, cinq une fourchette plus fiable : le Velocity Range Calculator de Mountain Goat Software demande au moins cinq vélocités passées. D'ici là, une nouvelle équipe planifie ses sprints à partir de sa capacité, en découpant les stories en tâches, et traite ses premières vélocités comme des mesures, pas des objectifs.
Sources
- Ken Schwaber et Jeff Sutherland, The Scrum Guide, 2020
- Mike Cohn, Why I Prefer Capacity-Driven Sprint Planning, Mountain Goat Software
- Mike Cohn, Should You Re-Estimate Unfinished Stories?, Mountain Goat Software
- Mike Cohn, Three Approaches to Estimating the Impact of Holidays and Time Off on Velocity, Mountain Goat Software
- Mountain Goat Software, Agile Planning and Forecasting et Velocity Range Calculator
- Atlassian, La vélocité des sprints dans Scrum et Que sont les story points ?
- Ron Jeffries, Story Points Revisited, 2019
- Wikipédia, Loi de Goodhart
Donnez à votre vélocité des estimations solides
Une vélocité fiable commence par des estimations sur lesquelles toute l'équipe est d'accord. Créez une session Planning Poker gratuite, estimez vos prochaines stories ensemble et exportez les résultats en CSV ou PDF pour votre outil de backlog. Sans inscription. Découvrez toutes les fonctionnalités.
