La vélocité d'équipe en agile : comment la mesurer et l'exploiter (+ calculateur gratuit)

La « Team Velocity » est un élément d’entrée pour les prévisions, et non un indicateur clé de performance (KPI). Dès que vous évaluez les équipes sur ce critère, les chiffres sont gonflés.

La vélocité correspond au nombre moyen de points d’histoire qu’une équipe réalise par sprint, calculé sur la base 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 l’ensemble du backlog, compte tenu du rythme de livraison réel de l’équipe. Additionnez les points restants, divisez-les par la vélocité, et vous obtenez une prévision. C’est, en toute honnêteté, sa seule utilité.

Toute autre utilisation fausse le résultat. « Pourquoi la vélocité était-elle 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 surévaluant le volume d’un même travail plutôt qu’en en accomplissant davantage. C’est la loi de Goodhart qui s’applique à un cycle de deux semaines.

Une petite mise en garde honnête avant de passer au guide pratique : le Guide Scrum ne fait pas mention de la vélocité. Il s’agit d’une pratique courante qui s’ajoute à Scrum, et non d’une règle de cette méthode, ce qui explique précisément pourquoi il convient de bien réfléchir à l’usage que vous en faites.

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

Prenez les points obtenus lors de chacun des trois à cinq derniers sprints. Calculez leur moyenne. Vous obtenez ainsi votre vélocité.

Un exemple concret, sur trois sprints :

Sprint	Points de scénario réalisés
Sprint 7	21
Sprint 8	34
Sprint 9	26

Vitesse = (21 + 34 + 26) divisé par 3 = 27 points par sprint.

Si le backlog comporte encore 210 points, la prévision correspond à 210 divisé par 27, soit environ 8 sprints. Les valeurs saisies allant de 21 à 34, la formulation la plus honnête est « sept à dix sprints », et non « 7,8 sprints ». Ou bien, évitez les calculs et laissez la calculatrice ci-dessus s’en charger à votre place.

Les règles qui garantissent la fiabilité des chiffres : ne tenez pas compte des sprints « exceptionnels », car ceux-ci font partie du signal que vous essayez de lisser. Ne comptez pas deux fois le travail reporté, et ne tenez absolument pas compte des stories partiellement achevées. Celles-ci ne sont prises en compte que dans le sprint au cours duquel elles sont effectivement terminées. Plus le calcul est simple, plus il est difficile de le contourner.

La vélocité se stabilise une fois que l’équipe a travaillé ensemble pendant trois ou quatre sprints. La formation d’une nouvelle équipe, l’adoption d’un nouveau scénario de référence ou un changement important au sein de l’effectif sont autant de raisons de ne plus tenir compte du chiffre précédent et de repartir de zéro. Ce chiffre n’est pas une caractéristique inhérente à la technique. Il s’agit d’une caractéristique propre à cette équipe à ce moment précis. Une équipe qui a perdu deux membres hier présente une vélocité correspondant à celle d’une autre équipe.

Utiliser la vélocité pour planifier le prochain sprint

Velocity fait ses preuves lors de la planification des sprints, et la méthode est simple :

1. Partez de la moyenne mobile des trois à cinq derniers sprints, jamais du résultat d’un seul sprint, et jamais de votre meilleur sprint.
2. Tenez compte des changements connus en matière d’effectifs. Deux personnes en congé lors du prochain sprint ? Un jour férié ? Réduisez l’objectif proportionnellement avant la planification, et non pas après coup, en vous excusant. La vélocité repose sur l’équipe qui l’a générée, et l’équipe du prochain sprint est parfois plus réduite.
3. Prévoyez un volume inférieur à la moyenne, soit environ 80 à 90 % de celle-ci. Sélectionnez des tâches jusqu’à ce que leur total corresponde approximativement à ce chiffre, et prévoyez une marge pour le travail imprévu qui survient à chaque sprint, que vous l’ayez prévu ou non.
4. Faites des prévisions sous forme de fourchettes. Pour tout ce qui dépasse le prochain sprint, indiquez vos meilleurs et vos pires sprints récents comme limites. Les parties prenantes peuvent s’organiser en tablant sur « sept à dix sprints ». Elles ne peuvent pas s’organiser en se basant sur un chiffre précis qui s’avérerait erroné.

Utilisez la vélocité pour trois choses, et uniquement trois : estimer une date pour un périmètre connu (le périmètre divisé par la vélocité donne le nombre de sprints), déterminer ce qui peut être intégré au prochain sprint, et repérer quand quelque chose a changé (une baisse de 30 % est un signal qui mérite d’être abordé lors d’une rétrospective). Ce que vous ne pouvez pas faire avec cette donnée : la comparer à celle 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.

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 de ces chiffres n’est bon ou mauvais. Ils sont calibrés par rapport à l’histoire de référence de l’équipe.

La grande erreur : la vélocité comme indicateur de performance

Le mode de défaillance le plus courant : un responsable interprète un chiffre de vélocité comme un indicateur de la « productivité de cette é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 même sens qu’auparavant. Les prévisions qu’elle était censée fournir sont désormais erronées.

Deuxièmement : la comparaison entre équipes. Deux équipes évaluant un backlog de même taille obtiennent des chiffres de vélocité différents, car elles utilisent des « stories » de référence différentes, ce qui est justement l’essence même 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.

Vous souhaitez que les calculs soient effectués à votre place ? Retournez sur le calculateur de vitesse gratuit et testez-y vos propres sprints.

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 a posteriori, 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 est devenue plus rapide, donc les anciennes stories devraient être plus petites » 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 procéder à une nouvelle estimation concerne les travaux reportés. Une tâche n’a pas été achevé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 identifié au moins un imprévu et a une vision plus claire de ce qu’il 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 défini comme « une journée-personne de travail pour un ingénieur moyen » ; ainsi, un 5 dans l’équipe A a la même signification qu’un 5 dans l’équipe B, et leurs vélocités peuvent ê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 de manière déguisée, simplement 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 de l’appliquer lors de la synthèse des chiffres. Chaque équipe continue d’estimer en fonction de son propre scénario 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 de story 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 diminué, 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, c’est-à-dire une histoire qu’elle a livrée avec les outils qu’elle utilise actuellement, et l’étalonnage tiendra déjà compte de toute accélération existante.

Il y a deux points sur lesquels il faut insister. L’affirmation « La vélocité a augmenté de 30 %, engageons-nous à l’augmenter encore de 30 % » comptabilise 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 a diminué, 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 à apprendre n’est pas devenu plus simple pour autant.

Réalisez ensemble vos estimations dans TeamRetro

La qualité de Velocity dépend entièrement de la qualité des estimations sur lesquelles il repose. TeamRetro Estimations organise une séance de « planning poker » avec votre équipe, en direct ou de manière asynchrone ; ainsi, les points que vous saisissez dans ce calculateur reflètent l’avis de l’ensemble de l’équipe, et non la supposition d’une seule personne. Essayez TeamRetro Estimations, ou commencez par l’outil de planning poker gratuit.

Foire aux questions

Qu’est-ce que la vélocité d’une équipe dans une méthode agile ?

La vélocité d’une équipe correspond au nombre moyen de points de story qu’une équipe réalise par sprint ; elle est généralement calculée sur la base des trois à cinq derniers sprints. Il s’agit d’un élément de planification, utilisé pour estimer le volume de travail pouvant être réalisé lors du prochain sprint et le temps nécessaire pour traiter le backlog ; ce n’est pas un indicateur de la qualité de l’équipe.

Comment calculez-vous la vélocité d’une équipe ?

Additionnez les points de story réalisés au cours de chacun des trois à cinq derniers sprints et calculez la moyenne. Si vos trois derniers sprints ont totalisé respectivement 21, 34 et 26 points, votre vélocité est de 27. Ne prenez en compte que les stories terminées, au cours du sprint où elles ont été achevées, ou utilisez le calculateur gratuit disponible sur cette page pour effectuer ces calculs.

Qu’est-ce qu’une bonne vélocité d’équipe ?

Une vélocité stable. Il n’existe pas de valeur de référence, car les points de chaque équipe sont calibrés en fonction de son propre scénario de référence ; ainsi, 15, 40 ou 100 peuvent tous être des chiffres satisfaisants. Une bonne vélocité est celle sur laquelle vous pouvez vous appuyer pour planifier, et non un chiffre qui ne cesse d’augmenter.

Faut-il comparer la vélocité entre les équipes ?

Non. Chaque équipe calibre ses points par rapport à des scénarios de référence différents ; leurs vitesses ne sont donc pas exprimées dans les mêmes unités. Les comparer revient à comparer deux thermomètres dont les points zéro ne coïncident pas. De plus, les comparaisons entre équipes incitent ces dernières à gonfler leurs estimations, ce qui fausse les prévisions que la vitesse est censée permettre d’établir.

Et si nous n’utilisions pas de points pour l’estimation, mais par exemple les tailles de t-shirt ?

Vous pouvez toujours suivre un débit approximatif, mais vous ne pouvez pas obtenir une valeur de vélocité exacte directement à partir des tailles de t-shirts, car celles-ci ne s’additionnent pas. Deux options s’offrent à vous. Commencez par associer les tailles à une échelle de points simple (par exemple XS = 1, S = 2, M = 3, L = 5, XL = 8), additionnez le nombre d’articles terminés à chaque sprint, et considérez le résultat comme une tendance générale plutôt que comme un chiffre précis. Ou bien, si vos éléments sont généralement de taille similaire, comptez plutôt le débit : le nombre d’éléments terminés par sprint. Ces deux méthodes sont moins précises que la vélocité en points ; interprétez-les donc comme une orientation générale, et non comme des décimales. Lorsque vous avez besoin d’une véritable prévision, réévaluez le travail à court terme en points. Consultez notre guide sur la classification par taille de t-shirt pour connaître la correspondance entre les tailles et les points.

Comment prendre en compte le travail qui n’est pas enregistré sous forme d’éléments quantifiés ?

La vélocité ne reflète que le travail que vous évaluez et suivez réellement. Les tickets d’assistance, les réunions, les interruptions et les corrections de bogues non chiffrées mobilisent tout de même de la capacité ; ainsi, si une grande partie de ce travail reste invisible, votre vélocité paraîtra inférieure à l’effort réel de l’équipe et vos prévisions s’avéreront trop optimistes. Voici deux solutions efficaces. Enregistrez le travail récurrent non planifié sous forme de tâches chiffrées afin qu’il soit pris en compte dans la vélocité au même titre que le reste. Ou bien réservez-lui ouvertement de la capacité, en vous engageant à en consacrer environ 80 à 90 % de votre moyenne et en conservant le reste comme Slack. N’attribuez pas a posteriori des points à du travail invisible dans le seul but de gonfler le chiffre, car cela fausse l’étalonnage dont dépend la vélocité.

Comment gérez-vous les retouches dans Velocity ?

Les retouches représentent un réel effort, mais le fait de réévaluer une tâche déjà considérée comme terminée nuit à la vélocité. Traitez les retouches comme du travail nouveau : créez un nouvel élément, évaluez-en la taille et comptabilisez-le dans le sprint au cours duquel il est achevé. Ne rouvrez pas la story d’origine pour la réévaluer. Si des retouches continuent d’apparaître, il s’agit d’un indicateur de qualité qui mérite d’être abordé lors d’une rétrospective, et non d’un ajustement de la vélocité. La prévision ne reste fiable que si chaque point n’est compté qu’une seule fois, dans le sprint où le travail a effectivement été achevé.

Quel est le nombre habituel de points d’histoire par sprint ?

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. 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 propre à 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. Sélectionnez 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 l’on attribue une note à la vélocité, 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 d’augmenter.

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é vient 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 l’avancement des points qu’elles se sont engagées à réaliser au cours d’un sprint.
• Techniques d’estimation agiles : quelle est la place de la vélocité parmi le Planning Poker, les points d’histoire et les autres méthodes, et laquelle utiliser dans quelle situation ?
• Guide d’estimation agile : l’ensemble complet des méthodes d’estimation.
• Planning Poker gratuit pour les équipes agiles : estimez les points qui constituent la vélocité.