Vélocité Scrum : définition, calcul et pièges à éviter

Ecrit par Matthieu Sanogho

4.5/5 - (2 votes)

compteur de vitesse d'une équipe agile

Mon article en bref

La vélocité est le nombre de points d’estimation qu’une équipe termine réellement sur un sprint. C’est un outil de prévision destiné à l’équipe elle-même — et le plus détourné de tous les indicateurs agiles dès qu’on en fait une mesure de performance.

Voici les points essentiels à retenir :

  • Définition : la somme des points des éléments réellement terminés sur un sprint, au sens de la definition of done.
  • Calcul : vélocité moyenne = total des points terminés ÷ nombre de sprints, sur 3 à 5 sprints minimum.
  • Ce qui compte : la stabilité de la série, jamais son niveau absolu.
  • Usage légitime : estimer un horizon de livraison et dimensionner le prochain sprint.
  • Non comparable : les vélocités de deux équipes ne se comparent pas, les échelles étant propres à chacune.
  • Le Guide Scrum ne mentionne pas la vélocité une seule fois : c’est une pratique, pas une règle du framework.

La vélocité, ou velocity en anglais, est la quantité de travail qu’une équipe Scrum termine effectivement au cours d’un sprint, exprimée dans son unité d’estimation — le plus souvent des story points. Ce n’est ni une vitesse, ni un rendement : c’est une observation de ce que l’équipe a livré, utilisée ensuite pour prévoir ce qu’elle livrera.

La nuance est mince à l’énoncé et lourde de conséquences en pratique : selon qu’on la traite comme une prévision ou comme un objectif, la vélocité devient l’un des indicateurs les plus utiles de l’agilité ou l’un des plus toxiques. Voyons sa définition exacte, comment la calculer sur un cas concret, ce qu’elle permet réellement de prévoir, et pourquoi elle ne mesure pas la productivité.

Qu’est-ce que la vélocité en Scrum ? Définition

régularité du rythme de livraison

La vélocité est la somme des points d’estimation des éléments terminés pendant un sprint. Le mot important est « terminés » : seuls comptent les éléments qui satisfont la definition of done de l’équipe. Un item à 80 % de son avancement vaut zéro point dans le sprint où il n’a pas abouti — il rapportera ses points au sprint suivant.

Cette règle du tout ou rien paraît sévère. Elle est en réalité la condition de la valeur prédictive de l’indicateur : si l’on comptabilise du travail partiellement fait, la vélocité mesure l’activité plutôt que la livraison, et ne prévoit plus rien.

Une unité propre à chaque équipe

La vélocité s’exprime dans l’unité d’estimation de l’équipe, et elle n’a de sens qu’à l’intérieur de cette équipe. Une équipe à 40 points par sprint n’est pas deux fois plus efficace qu’une équipe à 20 : elle a calibré son échelle différemment, avec des user stories découpées autrement. Il n’existe aucune valeur cible universelle.

Ce que le Guide Scrum en dit : rien

Point rarement relevé, y compris par les équipes chevronnées : le Guide Scrum 2020 ne contient aucune occurrence du mot « velocity », ni d’ailleurs de « story point » ou d’« estimate ». Il évoque uniquement le fait de dimensionner les éléments du Product Backlog, sans prescrire ni unité ni indicateur.

La vélocité n’est pas une règle de Scrum : c’est une pratique que les équipes ont ajoutée au framework, et qu’elles peuvent donc adapter ou abandonner.

C’est libérateur : une équipe qui décide de ne pas suivre sa vélocité, ou de la remplacer par un décompte d’éléments terminés, ne s’écarte pas du cadre. L’Agile Alliance la présente elle aussi comme un outil de planification empirique, pas comme une obligation.

Comment calculer la vélocité d’une équipe ?

moyenne sur plusieurs sprints

Le calcul est volontairement simple. Pour un sprint donné, on additionne les points des éléments terminés. Pour obtenir la vélocité moyenne, on divise le total des points terminés par le nombre de sprints observés :

Vélocité moyenne = total des points terminés ÷ nombre de sprints

Une seule mesure ne vaut rien : il faut 3 à 5 sprints pour qu’une moyenne devienne exploitable, et il est d’usage d’écarter les sprints atypiques (arrivée d’un nouveau membre, incident de production, période de congés) plutôt que de les laisser écraser la série.

Exemple de calcul sur quatre sprints

SprintPoints engagésPoints terminésÉcart
Sprint 12618−8
Sprint 22221−1
Sprint 32223+1
Sprint 42422−2
Moyenne23,521−2,5

La vélocité moyenne de cette équipe est de 21 points. Deux enseignements en découlent, et le second est le plus intéressant. D’abord, l’équipe s’engage régulièrement sur un peu plus qu’elle ne termine — un écart de 2 à 3 points, sans gravité. Ensuite, la série se resserre : après un premier sprint erratique, les trois suivants tiennent dans une fourchette de 21 à 23. C’est cette convergence, et non le chiffre de 21, qui rend la vélocité utilisable.

Calculateur de vélocité moyenne

Calculez la vélocité moyenne de votre équipe

Saisissez les points terminés de vos derniers sprints. Laissez vide ce que vous n’avez pas.

Saisissez au moins trois sprints pour une moyenne exploitable.

Une moyenne sur moins de trois sprints n’a pas de valeur prédictive. Si l’écart entre votre sprint le plus faible et le plus fort dépasse 30 %, votre vélocité n’est pas encore stabilisée.

Comment stabiliser une vélocité erratique

Une vélocité qui saute de 12 à 35 puis retombe à 18 n’est pas exploitable. Dans la quasi-totalité des cas, l’instabilité ne vient pas de l’équipe mais de la façon dont le travail entre dans le sprint. Quatre leviers, dans l’ordre d’efficacité :

  1. Découper plus finement — tant que des éléments à 13 ou 21 points entrent dans les sprints, un seul item non terminé fait plonger la vélocité. Viser des éléments à 1, 2, 3 ou 5 points lisse mécaniquement la série.
  2. Affiner en amont — un backlog refinement régulier réduit l’incertitude avant l’engagement, donc les mauvaises surprises en cours de sprint.
  3. Protéger le périmètre du sprint — chaque ajout en cours de route se paie par un élément non terminé, et donc par des points perdus.
  4. Garder l’équipe stable — chaque changement de composition remet le calibrage à zéro : la vélocité doit alors se réobserver sur trois nouveaux sprints.

Un point de vigilance pour finir : une vélocité qui grimpe régulièrement n’est pas forcément une bonne nouvelle. Elle peut signaler une équipe qui apprend, comme une équipe qui gonfle ses estimations ou qui rogne sur la qualité pour tenir un chiffre. La rétrospective est le bon endroit pour distinguer les deux.

En vidéo : le calcul de la vélocité d’une équipe agile, pas à pas (chaîne I Love Consulting).

À quoi sert vraiment la vélocité ?

prévoir une date de livraison

La vélocité a deux usages légitimes, et deux seulement. Le premier est la prévision d’horizon : connaissant la vélocité moyenne et le volume de points restant au backlog produit, l’équipe peut annoncer un nombre de sprints plutôt qu’une date ferme. Sur l’exemple ci-dessus, 100 points restants représentent environ cinq sprints, à présenter comme une fourchette de quatre à six.

Le second est le dimensionnement du prochain sprint. Pendant le sprint planning, la vélocité donne un repère pour ne pas surcharger l’engagement — sans jamais devenir un quota à atteindre.

  • Prévoir un horizon — combien de sprints pour tel périmètre, exprimé en fourchette.
  • Dimensionner un sprint — un plafond raisonnable pour l’engagement à venir.
  • Repérer une dérive — une vélocité qui s’effondre ou s’envole signale un problème à examiner en rétrospective, pas une faute à sanctionner.

💡 Astuce — communiquez toujours la vélocité en fourchette (« 4 à 6 sprints ») et jamais en date unique. La fourchette porte l’incertitude ; la date la dissimule et vous engage sur ce que vous ne maîtrisez pas.

Pourquoi la vélocité n’est pas un indicateur de performance

vélocité transformée en objectif de performance

C’est le détournement le plus répandu, et il suit toujours le même enchaînement. Un manager découvre la vélocité, y voit une mesure enfin chiffrée du travail d’une équipe, et en fait un objectif. L’équipe, qui n’est pas naïve, réagit rationnellement : elle gonfle ses estimations. Les mêmes fonctionnalités valent désormais 8 points au lieu de 5. La vélocité progresse de 60 %, la valeur livrée n’a pas bougé d’un iota.

Le mécanisme est connu sous le nom de loi de Goodhart : lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure. La vélocité y est particulièrement exposée puisque l’équipe qui la produit contrôle entièrement l’unité dans laquelle elle s’exprime.

Quatre dérives à reconnaître

  • En faire un objectif chiffré — l’inflation des estimations est immédiate et irréversible.
  • Comparer deux équipes — les échelles sont incommensurables, la comparaison ne mesure rien.
  • L’inscrire dans une évaluation individuelle — la vélocité est collective par construction ; l’individualiser détruit la coopération qu’elle suppose.
  • Compter le travail non terminé — l’indicateur perd sa valeur prédictive et devient un simple relevé d’activité.

Ce que la vélocité ne dit pas mérite d’être énoncé aussi clairement : elle ignore la valeur livrée, la qualité du produit, la satisfaction des utilisateurs et la dette technique accumulée. Une équipe peut afficher une vélocité exemplaire en produisant des fonctionnalités que personne n’utilise. Pour mesurer l’impact, il faut sortir des artefacts Scrum et regarder des indicateurs produit.

S’il faut n’en retenir qu’une chose, la voici : la vélocité appartient à l’équipe. C’est un instrument de bord qu’elle utilise pour se piloter, au même titre que les autres repères de la méthode Scrum. Dès qu’elle sort de l’équipe pour remonter dans un tableau de suivi, elle cesse presque toujours de mesurer ce qu’on croit qu’elle mesure.

FAQ — Tout savoir sur la vélocité en Scrum

Quelle est la formule de la vélocité en Scrum ?

La vélocité d’un sprint est la somme des points d’estimation des éléments terminés au sens de la definition of done. La vélocité moyenne s’obtient en divisant le total des points terminés par le nombre de sprints considérés, idéalement trois à cinq.

Quelle est une bonne vélocité pour une équipe Scrum ?

Il n’existe aucune valeur de référence. La vélocité dépend de l’échelle d’estimation de l’équipe, de son effectif et de la durée de ses sprints. Une bonne vélocité est une vélocité stable d’un sprint à l’autre, quel que soit son niveau.

Sur combien de sprints faut-il calculer la vélocité ?

Trois sprints au minimum, cinq de préférence. En deçà, la moyenne reste trop sensible aux aléas d’un sprint isolé pour servir de base de prévision. Les sprints atypiques peuvent être écartés du calcul plutôt que de déformer la série.

Peut-on comparer la vélocité de deux équipes ?

Non. Chaque équipe calibre sa propre échelle d’estimation, si bien qu’un point n’a pas la même signification d’une équipe à l’autre. Comparer deux vélocités revient à comparer des grandeurs exprimées dans des unités différentes.

Que faire d’un élément non terminé à la fin du sprint ?

Il ne rapporte aucun point au sprint qui s’achève et retourne au backlog avec son estimation d’origine. Il comptera intégralement dans la vélocité du sprint où il sera réellement terminé. On ne fractionne pas les points au prorata de l’avancement.

La vélocité est-elle obligatoire en Scrum ?

Non. Le Guide Scrum 2020 ne mentionne pas la vélocité une seule fois. C’est une pratique complémentaire, largement adoptée mais facultative : une équipe peut lui préférer un décompte d’éléments terminés ou un suivi de flux sans s’écarter du framework.

Quelle différence entre vélocité et capacité ?

La vélocité est une donnée observée, constatée après coup sur les sprints passés. La capacité est une projection pour le sprint à venir, ajustée aux conditions connues : congés, jours fériés, arrivées ou départs. On part de la vélocité pour estimer la capacité.

4.5/5 - (2 votes)
Matthieu Sanogho

Matthieu Sanogho

Product Manager avec plus de 10 ans d’expérience dans la gestion de produits digitaux axés data, IT et e-commerce, je suis passionné par l’optimisation de l'expérience utilisateur.

🎯 Mon objectif : faire le lien entre la compréhension des besoins clients, l’amélioration continue des parcours utilisateurs et la réalisation d’objectifs business.

User research : définition, méthodes et comment choisir

Story mapping : définition, méthode et exemple de story map