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 ?
Trois sprints terminés donnent une première base et cinq ou davantage permettent souvent de mieux voir la variabilité, mais il n'existe pas de seuil universel de fiabilité. La vélocité reste une observation locale, pas une prédiction garantie. Un changement significatif de composition ou de contexte rend les périodes avant et après moins comparables : il faut alors interpréter l'historique avec prudence.
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 un élément de contexte du Sprint Planning, au même titre que l'objectif, la capacité disponible, la Definition of Done et la nature du travail. Une démarche prudente consiste à :
- observer plusieurs sprints récents et comparables sans masquer leur dispersion ;
- tenir compte des absences et changements de contexte connus ;
- formuler le Sprint Goal, puis laisser les Developers prévoir les items nécessaires et construire leur plan ;
- inspecter le résultat au fil du sprint et adapter le périmètre avec le Product Owner sans mettre le Sprint Goal en danger.
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.
Prévoir une marge, sans en faire une règle universelle
Planifier exactement à 100 % de la moyenne historique laisse peu de place aux variations. Certaines équipes gardent une marge et sélectionnent environ 80 à 85 % de cette référence. Ce pourcentage est une heuristique à tester, pas une règle Scrum : l'objectif de sprint, les absences et la nature du travail doivent primer.
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
Le planning de Manifst calcule une référence à partir des trois derniers sprints terminés et affiche le minimum, la moyenne et le maximum. Cette moyenne préremplit une vélocité cible que l'équipe peut ajuster.
La sélection des tickets reste manuelle. Manifst additionne les story points choisis, signale les tickets non estimés et alerte lorsque la cible ou le ratio historique de points par jour-homme est dépassé. La capacité tient compte des jours disponibles saisis pour chaque membre.
Dans la Sprint Review, seuls les tickets réellement terminés alimentent les points réalisés. Le temps saisi sert de son côté au coût réel et au pilotage EVM, sans créer de conversion automatique entre heures et story points. Découvrir le planning et les reviews.
Essayez Manifst gratuitement : 1 projet, 5 membres, sans carte bancaire ; budget EVM inclus.