La vitesse : à quoi sert-elle et comment la calculer ?

La vélocité est un indicateur utilisé pour établir des prévisions, et non un indicateur clé de performance (KPI). Dès que vous évaluez les équipes sur ce critère, elle est surestimée.

La vélocité correspond au nombre moyen de points d’histoire qu’une équipe a traités par sprint au cours des derniers sprints. C’est là toute sa définition. Elle n’a qu’une seule utilité : estimer le nombre de sprints nécessaires pour livrer le backlog, compte tenu du rythme de livraison réel de l’équipe. Il suffit d’additionner les points restants, de diviser le total par la vélocité, et vous obtenez une prévision. C’est, en toute honnêteté, sa seule fonction.

Toute autre utilisation fausse le résultat. « Pourquoi la vélocité a-t-elle été plus faible lors de ce sprint ? » transforme chaque rétrospective en une défense de ce chiffre. « L’équipe A a une vélocité supérieure à celle de l’équipe B » considère que les calibrages indépendants de ces deux équipes sont comparables, alors qu’ils ne le sont pas. « Nous devons augmenter la vélocité de 20 % ce trimestre » incite l’équipe à faire grimper ce chiffre, et c’est ce qu’elle fera — en surestimant le volume d’un même travail, et non en en accomplissant davantage. La loi de Goodhart, appliquée à un cycle de deux semaines.

Comment le calculer ?

Prenez les points réalisés au cours de chacun des trois à cinq derniers sprints. Calculez leur moyenne. Vous obtenez ainsi votre vélocité. Ne tenez pas compte des sprints « exceptionnels » : ces derniers font partie du signal que vous essayez de lisser. Ne comptez pas deux fois le travail reporté. Ne tenez absolument pas compte des stories partiellement achevées ; elles sont comptabilisées dans le sprint au cours duquel elles sont effectivement terminées. Plus le calcul est simple, plus il est difficile de le manipuler.

La vélocité se stabilise une fois qu’une équipe a travaillé ensemble pendant trois ou quatre sprints. Une nouvelle équipe, un nouveau scénario de référence, un changement important au sein du personnel : autant de raisons de faire table rase des chiffres antérieurs et de repartir de zéro. Ce chiffre n’est pas une caractéristique de la technique ; c’est une caractéristique de cette équipe à ce moment précis. Une équipe qui a perdu deux membres hier présente une vélocité qui correspond à celle d’une autre équipe.

Combien de points d’histoire par sprint ?

Rechercher « combien de points d’histoire par sprint » relève d’une erreur de catégorie. Il n’existe pas de chiffre standard dans le secteur, pas de « bon » chiffre, ni de taux par développeur et par jour. La vélocité correspond au débit mesuré de l’équipe, et la seule valeur utile est la moyenne mobile calculée sur les derniers sprints de l’équipe. Quinze points, quarante points, cent points… Aucun n’est juste ou faux. Ils sont calibrés par rapport à l’histoire de référence de l’équipe.

Utilisez donc la vélocité pour faire trois choses, et uniquement trois : estimer une date pour un périmètre connu (périmètre ÷ vélocité = nombre de sprints) ; déterminer ce qui peut être intégré au prochain sprint (sélectionnez des stories jusqu’à ce que leur total représente environ 80 à 90 % de la moyenne récente, en laissant une marge pour l’imprévu) ; et repérer quand quelque chose a changé (une baisse de 30 % est un signal qui mérite une discussion lors de la rétrospective). Ce que vous ne pouvez pas faire avec cette donnée : la comparer aux chiffres d’une autre équipe, l’utiliser pour noter l’équipe, ou la convertir en « nombre d’heures prévues par développeur et par jour ». Chacune de ces pratiques constitue la même erreur sous une forme différente.

Qu’est-ce qui ne va pas ?

Le mode de défaillance le plus courant : un responsable interprète un chiffre de vélocité comme un indicateur de la productivité de son équipe. Ce chiffre est cité lors des réunions d’état d’avancement, puis comparé d’une équipe à l’autre, avant de devenir un objectif à atteindre. En l’espace de deux sprints, l’équipe a réévalué la taille de ses stories pour faire grimper ce chiffre — chaque story est désormais estimée à 30 % de plus qu’auparavant — et la vélocité n’a plus le sens qu’elle avait auparavant. Les prévisions qu’elle était censée fournir sont désormais erronées.

Deuxièmement : la comparaison entre équipes. Deux équipes évaluant le même backlog obtiennent des chiffres de vélocité différents, car elles utilisent des « stories » de référence différentes — c’est là tout l’intérêt de l’estimation relative. Les comparer revient à comparer deux thermomètres dont les points zéro ne coïncident pas. Ces chiffres n’ont pas la même signification, et les traiter comme s’ils en avaient une fausse l’étalonnage des deux équipes.

Quand procéder à une nouvelle estimation ?

La réévaluation du travail achevé ralentit la vélocité. La réévaluation du travail reporté est le seul cas où l’on agit en toute honnêteté.

La question revient chaque trimestre : « Nous avions estimé cela à 5, mais en réalité c’était un 13 — devrions-nous mettre à jour cette estimation ? » L’instinct qui vous pousse à répondre « oui » est le même qui veut que chaque chiffre soit correct rétrospectivement, et c’est une erreur. La vélocité correspond au rythme auquel l’équipe — selon l’étalonnage dont elle disposait à ce moment-là — a achevé son travail. Revenir en arrière et réévaluer les points revient à réévaluer l’étalonnage lui-même, et les prévisions qui fonctionnaient auparavant cessent d’être valables. « L’équipe a gagné en rapidité, donc les anciennes stories devraient être plus courtes » supprime le seul indicateur montrant que l’équipe s’est améliorée. « Ce 5 s’est avéré être un 13 » est un indicateur permettant d’affiner l’estimation de la prochaine story similaire, et non un prétexte pour réécrire l’historique de celle-ci.

Le seul cas où vous devriez réévaluer le travail est celui du report. Une story n’est pas terminée, le sprint touche à sa fin, et le travail restant est reporté dans l’engagement du sprint suivant. Ce travail restant diffère sensiblement de ce qui avait été évalué au départ : l’équipe en a déjà réalisé une partie, a rencontré au moins un imprévu et a désormais une vision plus claire de ce qui reste à faire. Réévaluez-le comme s’il s’agissait d’une nouvelle tâche, en utilisant l’estimation initiale comme référence plutôt que comme une contrainte.

Harmonisation de la vitesse entre les équipes

La normalisation est avant tout un rituel SAFe visant à garantir la cohérence d’un tableau de bord de portefeuille. Évitez de vous y plier, à moins qu’un de vos supérieurs n’ait réellement besoin de ce tableau de bord.

La normalisation permet à deux équipes ou plus de s’accorder sur un critère de référence commun — généralement quelque chose comme « une journée-personne de travail pour un ingénieur moyen » — de sorte qu’un 5 dans l’équipe A ait la même signification qu’un 5 dans l’équipe B, et que leurs vélocités puissent être additionnées. La technique fonctionne : un 5 normalisé a bel et bien la même signification pour toutes les équipes qui s’y sont mises d’accord. Le problème réside dans ce que vous avez dû sacrifier pour y parvenir. Vous avez troqué la propriété d’estimation relative de chaque équipe contre une estimation absolue — ce qui revient à estimer la durée sous une autre forme — uniquement pour pouvoir calculer une moyenne entre des équipes qui ne partagent ni base de code, ni pile technologique, ni domaine d’expertise.

Si une prévision au niveau du portefeuille sert véritablement à financer le travail (et non pas simplement à comparer les équipes), effectuez la normalisation au niveau de la synthèse : demandez à la direction du programme de définir un multiplicateur de points par équipe, calibré une seule fois et rarement réévalué, et appliquez-le lors de la synthèse des chiffres. Chaque équipe continue d’estimer en fonction de sa propre histoire de référence ; le multiplicateur convertit la vélocité de l’équipe en unité de mesure du portefeuille, et les réunions de raffinement n’en tiennent jamais compte. Ce qu’il faut rejeter : la normalisation qui commence au sein d’une seule équipe, et la normalisation effectuée dans le but de faciliter la comparaison entre les équipes. Ce deuxième cas n’est pas un cas d’utilisation — c’est un anti-modèle sous un nom bien choisi.

Velocity et les outils de programmation basés sur l’IA

Copilot, Cursor, Claude Code. Les points ne changent pas. La vitesse, elle, change — mais seulement a posteriori.

La question revient dans toutes les équipes qui utilisent un assistant de codage basé sur l’IA depuis quelques mois : nous livrons plus rapidement, devrions-nous réévaluer le backlog ? Le « 3 » du trimestre dernier devrait-il devenir un « 5 » ce trimestre ? La réponse est non, car les points d’histoire n’ont jamais mesuré ce qui a changé. Les points mesurent la complexité relative et l’incertitude ; l’assistant réduit le temps de saisie consacré à une story, parfois de manière spectaculaire, mais la complexité reste inchangée, les inconnues restent inchangées, le risque d’intégration et les cas limites restent inchangés. Si vous réévaluez un 5 en 3 simplement parce que l’outil a rédigé le code standard et que vous revenez à une estimation en heures, vous vous trompez.

Ce qui change, c’est la vitesse. Une même équipe qui livre le même type de travail avec l’aide d’un assistant génère davantage de points par sprint qu’il y a six mois — non pas parce que les points ont perdu de leur valeur, mais parce que l’équipe est devenue plus rapide pour transformer ces points en code livré. C’est ce chiffre qui remplit parfaitement son rôle, et il se recalibre naturellement sur trois ou quatre sprints. Veillez à ce que l’histoire de référence de l’équipe soit récente — une histoire qu’elle a livrée avec les outils qu’elle utilise actuellement — et l’étalonnage tient déjà compte de toute accélération existante.

Deux points sur lesquels il faut insister. « La vélocité a augmenté de 30 %, engageons-nous à gagner 30 % de plus » revient à compter deux fois la même amélioration : la moyenne récente inclut déjà l’effet de l’IA, il ne faut donc pas la multiplier à nouveau. « Tout est devenu plus petit, réévaluons le backlog » : c’est le piège de la réévaluation évoqué plus haut — les stories n’ont pas diminué, c’est l’équipe qui est devenue plus rapide, et les prévisions en tiennent déjà compte. C’est face à l’incertitude que les outils sont les moins utiles : un assistant accélère certaines parties d’une enquête de spike, mais ce que le spike cherche à comprendre n’est pas devenu plus simple pour autant.

Foire aux questions

Combien de points d’histoire par sprint considère-t-on comme normal ?

Il n’existe pas de chiffre de référence dans le secteur. La vélocité correspond au débit mesuré de votre équipe, c’est-à-dire la moyenne mobile des points réalisés au cours des derniers sprints. Quinze, quarante, cent : aucun de ces chiffres n’est bon ou mauvais, car chacun est calibré par rapport à une histoire de référence différente.

Combien de points d’histoire par sprint et par développeur ?

N’en calculez pas. Un taux par développeur transforme les points d’histoire en heures déguisées et encourage la comparaison entre les personnes, ce que cette technique vise justement à éviter. La vélocité est un chiffre qui s’applique à l’équipe, et non la somme des quotas individuels.

Combien de points d’histoire y a-t-il dans un sprint de deux semaines ?

Quel que soit le nombre de tâches que votre équipe a habituellement accomplies au cours d’un sprint de deux semaines, mesurez-le, mais ne vous fixez pas cet objectif. Choisissez des stories jusqu’à ce que leur total représente environ 80 à 90 % de votre moyenne récente, et prévoyez une marge pour les imprévus.

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

Une vélocité stable. « Notre vélocité est-elle bonne ? » : voilà la question qui fait dérailler le système — dès que la vélocité est évaluée, les chiffres gonflent et rien n’est réellement livré plus rapidement. Une bonne vélocité est celle sur laquelle vous pouvez vous appuyer pour planifier, et non un chiffre qui ne cesse de grimper.

Lectures complémentaires

• Points de scénario vs heures — pourquoi la conversion des points en heures est le mode de défaillance que la vélocité est censée remplacer.
• Planification de la vélocité et de la capacité — utiliser la vélocité pour définir un engagement de sprint réaliste.
• Qu’est-ce qu’un graphique « burndown » ? — comment les équipes suivent les points qu’elles se sont engagées à réaliser au cours d’un sprint.
• Guide d’estimation agile — l’ensemble complet des ressources sur l’estimation.
• Planning Poker gratuit pour les équipes agiles — estimez les points qui composent la vélocité.