La vélocité Scrum est la métrique la plus citée dans les retrospectives, les sprint plannings et les tableaux de bord agiles. Presque chaque équipe la calcule. Très peu l'interprètent correctement — et certaines en font un outil contre-productif sans s'en rendre compte. Comprendre ce que la vélocité mesure vraiment, comment la calculer et surtout comment ne pas s'en servir, c'est l'une des compétences les plus sous-estimées du Scrum Master.
Vélocité Scrum : définition et ce qu'elle mesure vraiment
La vélocité Scrum est la somme des story points des user stories complétées — Definition of Done respectée — sur un sprint. Elle mesure la capacité de production historique d'une équipe, sprint après sprint.
Ce qu'elle n'est pas : une mesure de productivité individuelle, un objectif à maximiser, ni un outil de comparaison entre équipes.
Deux précisions importantes sur cette définition :
- "DoD respectée" — une story à 90 % n'est pas complétée. Seules les stories totalement terminées selon la Definition of Done comptent dans la vélocité. Une story reportée au sprint suivant ne génère aucun point.
- "Historique" — la vélocité ne prédit pas l'avenir avec précision. Elle décrit ce que l'équipe a fait dans des conditions comparables. C'est une estimation, pas une garantie.
Point peu connu : le terme "vélocité" n'apparaît pas dans le Guide Scrum 2020. Il en a été retiré précisément pour éviter qu'elle soit utilisée comme objectif de performance. C'est une métrique de l'espace de la pratique Scrum, pas un artefact officiel du framework.
Comment calculer la vélocité Scrum
La formule de base
Le calcul est simple :
Vélocité d'un sprint = Σ story points des stories complétées (DoD) pendant ce sprint
Exemple : au cours d'un sprint, l'équipe complète 4 stories de 3, 5, 8 et 5 points respectivement. La vélocité du sprint est 3 + 5 + 8 + 5 = 21 points.
Vélocité par sprint vs vélocité moyenne
Un sprint isolé ne suffit pas — la vélocité d'un sprint unique est trop sensible aux aléas (congés, bugs inattendus, onboarding d'un nouveau membre). La vélocité utile pour le sprint planning est la moyenne glissante, calculée sur les 3 à 5 derniers sprints comparables.
| Sprint | Points complétés | Contexte |
|---|---|---|
| Sprint 1 | 18 | Démarrage — référentiel pas encore calibré |
| Sprint 2 | 24 | Normal |
| Sprint 3 | 14 | 2 membres absents — résultat atypique |
| Sprint 4 | 26 | Normal |
| Sprint 5 | 23 | Normal |
| Moyenne (S2–S5) | 21,75 | → Prévision raisonnable : 20-22 points |
Le sprint 1 est exclu car le référentiel d'estimation n'était pas encore stabilisé. Le sprint 3 peut être noté mais interprété avec son contexte. La moyenne glissante sur les sprints "normaux" donne une prévision fiable pour le prochain sprint planning.
Combien de sprints pour une vélocité fiable ?
La règle communément admise : minimum 3 sprints, idéalement 5. En dessous de 3 sprints, les variations aléatoires dominent et la moyenne n'a pas de valeur prédictive. Un changement significatif dans l'équipe (départ, arrivée) remet le compteur à zéro — la vélocité d'une composition d'équipe ne se transfère pas à une autre.
Comment interpréter sa vélocité
Les signaux d'une vélocité saine
Une équipe mature présente un indicateur stable avec de légères variations — typiquement ±15 % autour de la moyenne sur des sprints comparables. Ce n'est pas une mauvaise nouvelle : la stabilité indique que l'équipe maîtrise son processus, que son référentiel d'estimation est cohérent et que ses engagements sont réalistes.
Les signaux d'alerte
| Signal | Cause probable | Action |
|---|---|---|
| Chute soudaine (−30 %+) | Absence, bug critique, dette technique | Investiguer en rétrospective |
| Hausse soudaine (+30 %+) | Inflation des estimations, stories trop faciles | Recalibrer le référentiel |
| Déclin progressif | Dette technique croissante, turnover | Sprint de remise à niveau |
| 100 % atteint chaque sprint | Sous-engagement volontaire, pression management | Revoir le processus de sprint planning |
Ce qu'une vélocité élevée ne signifie pas
Une vélocité de 60 points n'est pas "meilleure" qu'une vélocité de 25 points. Les story points sont relatifs à l'équipe — ils reflètent son référentiel interne, pas une unité universelle. Une équipe de 3 personnes avec 25 points peut livrer exactement autant de valeur qu'une équipe de 8 avec 60 points. Comparer des vélocités entre équipes est l'une des erreurs les plus fréquentes — et les plus nocives.
Vélocité et taille d'équipe
La taille de l'équipe influence mécaniquement la vélocité absolue sans rien dire sur l'efficacité relative. Une équipe de 8 personnes aura un total de points plus élevé qu'une équipe de 3 — mais le ratio points par personne peut être identique, voire inférieur pour la grande équipe, du fait du surcoût de coordination (réunions, revues, dépendances internes).
Le ratio points par personne (vélocité totale ÷ nombre de membres actifs) est parfois calculé pour détecter des dérives dans le temps — par exemple, si elle chute lors de l'intégration de nouveaux membres. À utiliser avec deux précautions : uniquement en comparaison de la même équipe sur des périodes similaires, et jamais pour évaluer des individus. Un développeur senior dédié à 80 % à de l'architecture contribue peu aux story points visibles tout en débloquant potentiellement toute l'équipe.
Vélocité et sprint planning
La vélocité est l'outil central du sprint planning : elle détermine le volume de stories que l'équipe peut raisonnablement s'engager à livrer. Le processus :
- Calculer la moyenne sur les 3-5 derniers sprints comparables
- Ajuster en fonction des absences connues du prochain sprint (réduire proportionnellement)
- Sélectionner les stories du backlog depuis le haut de la pile jusqu'à atteindre 80-90 % de la vélocité cible — pas 100 % (marge pour les imprévus)
- Confirmer l'engagement collectif de l'équipe
La vélocité comme outil de planification dépend entièrement de la qualité des estimations en story points. C'est pourquoi le planning poker est si critique : des estimations biaisées ou incohérentes rendent les prévisions inutilisables.
La règle des 80 %
Planifier à 100 % de la moyenne historique est une erreur systématique. Les imprévus existent toujours — un bug critique en production, une story plus complexe que prévu, une réunion imprévue. La règle pratique : engager 80 à 85 % de la moyenne historique, pas la totalité.
Illustration : si la moyenne est 40 points, sélectionner 32 à 34 points de stories. Si le sprint se déroule bien, l'équipe saisit une story supplémentaire en backlog. Si un imprévu surgit, le sprint goal reste atteignable. Une équipe qui planifie systématiquement à 100 % et rate régulièrement ses engagements finit par ne plus croire en ses propres estimations — ce qui dégrade le planning poker et, par cercle vicieux, la fiabilité des prévisions sprint après sprint.
Cette marge n'est pas du temps gaspillé : c'est la différence entre une équipe qui tient ses engagements et une équipe qui les négocie en permanence à la baisse.
Les 6 pièges qui faussent la vélocité
1. Compter les stories "presque finies"
C'est le piège le plus courant. Une story à 90 % est comptabilisée dans le total de points parce que "elle sera finie demain". Le lendemain du sprint, elle entre dans le sprint suivant avec le même statut. Résultat : le résultat affiché ne correspond pas à ce qui a été vraiment livré. La règle est absolue : seules les stories respectant la Definition of Done comptent.
2. Gonfler les estimations pour "améliorer" la vélocité
Sous pression managériale ("vos résultats doivent augmenter"), les équipes sur-estiment progressivement leurs stories. Une story qui valait 3 points en devient 5, puis 8. L'indicateur augmente sur le tableau de bord — mais le volume de valeur livrée reste identique. C'est ce qu'on appelle le point washing ou story point inflation. L'antidote : ne jamais utiliser cette métrique comme KPI de performance, et recalibrer régulièrement le référentiel avec des stories de référence connues.
3. Comparer des équipes entre elles
Les story points sont une mesure interne, relative au contexte et au référentiel de chaque équipe. Comparer les 30 points de l'équipe A aux 50 de l'équipe B pour conclure que B est "plus productive" est une erreur analytique fondamentale. La seule comparaison valide : celle d'une équipe avec elle-même, sur des sprints comparables.
4. Ignorer les changements de composition d'équipe
L'arrivée d'un nouveau membre, le départ d'un senior, un changement de Scrum Master — chacun de ces événements invalide la vélocité historique comme référence. Une nouvelle composition d'équipe doit reconstruire son référentiel sur 3 à 5 sprints avant de pouvoir l'utiliser pour planifier avec fiabilité.
5. Utiliser la vélocité comme objectif de management
"L'équipe doit atteindre 45 points ce sprint." Dès qu'une métrique devient un objectif, elle cesse de mesurer ce qu'elle était censée mesurer — c'est la loi de Goodhart, bien documentée en management agile. Cet outil est fait pour la prévision, pas pour la motivation. La fixer comme objectif génère inévitablement du point washing ou du burnout.
6. Confondre capacité et points de sprint
La capacité est le temps disponible de l'équipe (jours-hommes, congés déduits). Cette dernière représente la production historique en story points. Les deux sont liées mais distinctes : une équipe peut avoir 100 % de sa capacité disponible et produire moins que son ratio historique habituel (bug critique en cours de sprint, stories plus complexes que prévu). Planifier uniquement sur la capacité sans tenir compte de cet historique revient à ignorer la réalité empirique du sprint.
Vélocité vs autres métriques agiles
Ce n'est pas la seule métrique utile. Selon la maturité de l'équipe et le contexte, d'autres indicateurs la complètent :
- Burndown chart — montre en temps réel si le sprint est en bonne voie. Là où la première est rétrospective (mesurée après), le burndown est prospectif (visible pendant). Ces deux indicateurs sont complémentaires, pas interchangeables.
- Cycle time — temps moyen entre le début du développement d'une story et sa livraison. Utile pour identifier les goulots d'étranglement dans le processus, indépendamment des story points.
- Throughput — nombre de stories livrées par sprint, indépendamment de leur taille. Pertinent pour les équipes qui renoncent aux points et adoptent le "right-sizing" (toutes les stories de taille équivalente).
Pour la grande majorité des équipes qui débutent avec Scrum, la vélocité en story points reste l'indicateur le plus simple à implémenter et le plus directement utilisable pour la planification. Les métriques avancées (cycle time, flow metrics) gagnent en pertinence à partir de 12 à 18 mois de pratique.
Vélocité Scrum dans Manifst
Dans Manifst, le sprint planning intègre l'historique de l'équipe : l'assistant de planification la prend en compte pour suggérer le volume de stories à sélectionner, ce qui évite de surcharger ou sous-charger le sprint par rapport à la capacité réelle. Cette suggestion s'appuie sur les sprints précédents enregistrés dans le projet.
Le time tracking par user story permet par ailleurs de comparer le temps réel passé aux estimations en story points sprint après sprint — un signal précieux pour détecter les dérives du référentiel avant qu'elles faussent cet indicateur. Si une story estimée à 3 points consomme systématiquement deux fois plus de temps qu'une story à 5 points, le référentiel mérite d'être recalibré.
Lors de la sprint review, Manifst affiche les stories complétées et celles non terminées : seules les premières sont comptabilisées dans le total du sprint.
Essayez Manifst gratuitement — 1 projet, 4 membres, toutes les fonctionnalités incluses, sans carte bancaire.