1. Qu'est-ce que la Velocity Scrum ?
La Velocity Scrum (ou sprint velocity) est la quantité de Story Points qu'une équipe Scrum termine effectivement au cours d'un Sprint, selon sa Definition of Done. Autrement dit, c'est un indicateur empirique de débit qui aide l'équipe à mieux prévoir son prochain Sprint et sa release.
Elle est calculée a posteriori, à la fin de chaque Sprint, et se lisse généralement sur 3 à 5 Sprints pour obtenir une prévision fiable. Elle est propre à chaque équipe : une Velocity de 30 SP dans l'équipe A n'a strictement rien à voir avec une Velocity de 30 SP dans l'équipe B.
2. Pourquoi mesurer la Velocity ?
La Velocity remplit quatre fonctions concrètes :
- Prévoir le prochain Sprint : combien de Story Points l'équipe peut raisonnablement embarquer.
- Projeter une release : estimer le nombre de Sprints nécessaires pour terminer un Product Backlog priorisé.
- Détecter des signaux : chute brutale, forte variance, tendance à la baisse — autant de sujets pour la Sprint Retrospective.
- Négocier honnêtement avec les stakeholders : une Velocity mesurée est un argument factuel pour dire « non, pas ce Sprint ».
3. Comment calculer la Velocity ?
La formule est simple :
| Étape | Action | Détail |
|---|---|---|
| 1 | Lister les 3 à 5 derniers Sprints | Écarter les Sprints atypiques (livraison, formations) |
| 2 | Additionner les SP Done | Seuls les items 100 % conformes à la DoD comptent |
| 3 | Diviser par le nombre de Sprints | Obtenir la Velocity moyenne |
| 4 | Ajuster à la Capacity | Sprint spécifique (congés, taille d'équipe) |
| 5 | Communiquer une fourchette | Min × 0,9 → Max × 1,05 |
Formule condensée : Velocity = Σ(SP Done) / nombre de Sprints
4. Exemple concret
Une équipe Scrum termine les Sprints suivants :
| Sprint | Story Points Done | Commentaire |
|---|---|---|
| Sprint 1 | 20 | Démarrage — Sprint d'apprentissage |
| Sprint 2 | 24 | Équipe stabilisée |
| Sprint 3 | 30 | Pic — surestimation d'engagement |
| Sprint 4 | 26 | Rattrapage réaliste |
| Sprint 5 | 28 | Rythme de croisière |
Velocity moyenne : (20 + 24 + 30 + 26 + 28) / 5 = 25,6 SP. Pour le Sprint 6, l'équipe visera une fourchette entre ~23 et ~29 SP, en ajustant selon la Capacity réelle du Sprint (congés, formations, jours fériés).
5. Calculateur interactif
Utilisez ce calculateur pour projeter la Velocity de votre équipe à partir des 5 derniers Sprints. Les prévisions s'expriment sous forme de fourchette, pas d'une valeur unique.
Fourchette basée sur min × 0,9, moyenne, et max × 1,05. La Velocity est un indicateur probabiliste — jamais un engagement contractuel.
Sprint Simulator
Testez rapidement quel Sprint Backlog reste réaliste selon votre Velocity de référence :
Sous-engagé
Historique de Velocity
La Velocity se stabilise généralement entre le 3ᵉ et le 5ᵉ Sprint. Les variations de ±20 % sont normales.
6. Velocity vs Capacity : ne les confondez pas
Velocity et Capacity sont complémentaires, pas concurrentes. La Velocity mesure ce qui a été livré ; la Capacity prévoit combien de temps l'équipe aura le Sprint prochain.
| Critère | Velocity | Capacity |
|---|---|---|
| Nature | Mesure passée (SP réellement livrés) | Prévision future (heures/jours dispos) |
| Unité | Story Points par Sprint | Heures ou personne·jours |
| Usage | Prévoir le contenu d'un Sprint | Ajuster l'engagement selon les congés / absences |
| Horizon | Moyenne sur 3–5 Sprints | Sprint à venir |
| Décidé par | Les Developers (émergent) | Les Developers (calculé) |
| Dans le Scrum Guide ? | Non mentionné explicitement | Non mentionné explicitement |
Règle simple : la Capacity ajuste la Velocity pour un Sprint donné (ex. semaine de congés). Elles se complètent, elles ne se remplacent pas.
Base 28 SP · Variation +0 %
7. Velocity vs Story Points
Les Story Points sont l'unité ; la Velocity est le débit mesuré dans cette unité. Sans SP, pas de Velocity — mais on peut aussi mesurer un débit en nombre de stories ou en throughput (approche Kanban).
Plus les stories sont grosses, plus la variance de la Velocity augmente. Cibler des items entre 1 et 8 SP améliore la prévisibilité.
8. Velocity vs Burndown Chart
Le Burndown Chart visualise le travail restant à l'intérieur d'un Sprint ; la Velocity mesure le travail terminé à la fin d'un Sprint. Les deux se combinent naturellement :
| Outil | Mesure | Horizon |
|---|---|---|
| Velocity | SP Done par Sprint | Historique + prévision |
| Burndown Chart | SP restants au fil du Sprint | Un Sprint |
| Burnup Chart | SP terminés + scope total | Sprint ou release |
9. Les erreurs fréquentes sur la Velocity
Voici les 8 pièges qui reviennent le plus souvent dans les équipes — et dans les questions du PSM I :
Pourquoi : Les SP sont relatifs à une équipe. 20 SP ici ≠ 20 SP ailleurs.
Bonne pratique : Comparer les tendances, pas les valeurs absolues.
Pourquoi : Incite au gonflage d'estimations et détruit la confiance.
Bonne pratique : Traiter la Velocity comme un outil d'équipe, pas un objectif.
Pourquoi : Le max n'est pas reproductible. L'équipe finira sur-engagée.
Bonne pratique : Prendre la moyenne, ou la moyenne des 3 pires Sprints.
Pourquoi : Contredit la Definition of Done : seul l'Increment terminé compte.
Bonne pratique : N'ajouter au calcul que les items 100 % Done.
Pourquoi : Rend l'historique inutilisable et fausse toutes les prévisions.
Bonne pratique : Garder une échelle stable. Réaligner uniquement en cas de refonte de l'équipe.
Pourquoi : La Velocity chute progressivement, sans cause visible.
Bonne pratique : Réserver 15–20 % de la capacité à la dette et aux enablers.
Pourquoi : Un seul point ne fait pas une tendance. Marge d'erreur ±100 %.
Bonne pratique : Attendre 3 Sprints, idéalement 5, avant toute projection.
Pourquoi : Casse le Sprint Goal et biaise la Velocity du Sprint suivant.
Bonne pratique : Placer les nouveaux items dans le Product Backlog.
10. Comment améliorer sa Velocity ?
Attention : augmenter la Velocity n'est pas un objectif en soi. Ce qui compte est d'améliorer la valeur livrée et la prévisibilité. Cinq leviers efficaces :
- Découper les stories — viser 1 à 8 SP par item ( Planning Poker pour aligner l'équipe).
- Refiner en continu — un backlog propre alimente une Sprint Planning fluide.
- Réserver 15–20 % pour la dette technique — évite l'érosion silencieuse.
- Renforcer la Definition of Done — moins de reprises, plus de vraie Velocity.
- Retrospectives orientées action — 1 à 2 améliorations concrètes par Sprint.
Bonne, mauvaise, stable, instable : lire une courbe
Variance faible (< 10 %), prévisions fiables. La Definition of Done est probablement respectée.
Courbe croissante — typique des 3–5 premiers Sprints. Elle devrait se stabiliser bientôt.
Alternance forte : sur-engagement puis rattrapage. À investiguer en Retrospective.
Baisse continue. Le plus souvent : dette technique, turnover, ou stories mal découpées.
Testez vos connaissances
La Velocity est-elle définie dans le Scrum Guide ?
Velocity, Capacity ou Forecast : que choisir ?
- Prévoir le contenu du prochain Sprint
- Estimer une release (Product Backlog projeté)
- Suivre la stabilité de l'équipe sur plusieurs Sprints
- Sprint spécifique avec congés / formations
- Nouvelle composition d'équipe
- Sprint plus court ou plus long qu'habituel
- Horizon > 3 Sprints (release, roadmap)
- Historique riche (≥ 10 Sprints)
- Communication avec des stakeholders exigeants
11. Stabilité et fiabilité des prévisions
Une Velocity stable — variance inférieure à ~15–20 % sur 5 Sprints — permet des prévisions fiables. Une Velocity instable rend toute projection hasardeuse, même si sa moyenne semble « correcte ». Le graphique ci-dessous illustre ce contraste :
Velocity stable
→ prévisions fiablesFourchette étroite : le Sprint Planning est prévisible.
Velocity instable
→ prévisions peu fiablesFourchette large : les engagements deviennent risqués.
Avant de projeter une Sprint Planning ou une release, vérifiez d'abord la variance, pas seulement la moyenne. Une Velocity instable est un signal fort à instruire en Sprint Retrospective (dette technique, sur-engagement, DoD floue, dépendances externes).
12. Velocity vs Throughput, Lead Time, Cycle Time, Burn Up
La Velocity n'est qu'une métrique parmi d'autres. Les équipes matures la combinent avec des mesures de flux (Kanban) et des visualisations de trajectoire (Burn Up Chart, Burn Down Chart) pour piloter à la fois débit, latence et scope.
| Critère | Velocity | Capacity |
|---|---|---|
| Nature | Observée (a posteriori) | Prévue (a priori) |
| Unité | Story Points | Heures / jours-personnes |
| Horizon | 3 à 5 Sprints passés | Sprint à venir |
| Sert à | Prévoir le débit moyen | Ajuster l'engagement d'un Sprint spécifique |
| Sensible à | DoD, découpage, équipe | Congés, formations, jours fériés |
| Critère | Velocity | Throughput |
|---|---|---|
| Unité | Story Points par Sprint | Nombre d'items par période |
| Cadre | Scrum | Kanban / Scrumban |
| Prérequis | Estimation en SP | Découpage homogène des items |
| Avantage | Prend en compte la taille des items | Zéro estimation, très rapide à collecter |
| Limite | Dépend de la qualité des estimations | Ignore la taille — biaisé si items hétérogènes |
| Critère | Velocity | Lead Time |
|---|---|---|
| Ce qui est mesuré | Débit d'un Sprint | Délai perçu par le client (idée → livraison) |
| Point de départ | Début du Sprint où l'item est engagé | Création de la demande |
| Point d'arrivée | Fin du Sprint (Done) | Mise en production |
| Vision | Interne à l'équipe | Bout-en-bout produit |
| Complémentarité | Combien on livre | Combien de temps le client attend |
| Critère | Velocity | Cycle Time |
|---|---|---|
| Ce qui est mesuré | SP terminés par Sprint | Durée réelle de traitement d'un item |
| Point de départ | Sprint Planning | Passage en « In progress » |
| Point d'arrivée | Fin du Sprint | Passage en « Done » |
| Utilité | Prévoir un scope | Détecter goulots et attentes |
| Optimisation | Découper, refiner, stabiliser | Réduire WIP, éliminer les attentes |
| Critère | Velocity | Burn Up Chart |
|---|---|---|
| Format | Chiffre / série temporelle | Graphique cumulé (Done + scope) |
| Ce que ça montre | Débit récent | Trajectoire vers la release + scope creep |
| Horizon | Sprint à Sprint | Release / Product Goal |
| Force | Simple, empirique | Rend le scope creep visible |
| Combiné avec | Sprint Planning | Release Planning et négociation stakeholder |
13. 8 exemples sectoriels détaillés
Voici 8 cas concrets tirés de contextes très différents. Chacun illustre comment la Velocity doit être interprétée dans son contexte — jamais comparée telle quelle entre équipes.
Développement logiciel B2B
- Contexte
- Équipe de 6 développeurs, backend SaaS mature, Sprints de 2 semaines.
- Velocity
- 34 SP en moyenne, variance ±3.
- Interprétation
- Fourchette étroite : la Definition of Done est solide, le refinement continu.
- Décision
- Engagement Sprint = 32 SP + 2 SP de dette technique dédiés.
Banque — plateforme paiement
- Contexte
- Réglementation forte, DoD incluant audit sécurité et pen-tests.
- Velocity
- 18 SP, mais 6 SP consommés par la conformité invisible.
- Interprétation
- Velocity « faible » qui reflète la vraie complexité, pas un manque de productivité.
- Décision
- Ne pas comparer avec l'équipe front. Communiquer la fourchette 16–20 SP.
Cloud / plateforme interne
- Contexte
- Équipe SRE de 5, moitié run / moitié build.
- Velocity
- 22 SP planifiés, 15 SP réellement Done — 30 % consommé par l'astreinte.
- Interprétation
- La Capacity effective est bien inférieure à la Capacity nominale.
- Décision
- Baisser l'engagement à 15 SP et rendre l'astreinte visible dans le Sprint Backlog.
Migration SI legacy
- Contexte
- Refonte progressive, dépendances fortes avec ancien système.
- Velocity
- Très variable : 12, 28, 9, 22, 14.
- Interprétation
- Instabilité due aux surprises legacy — pas à l'équipe.
- Décision
- Piloter par pourcentage de scope migré (Burn Up) plutôt que par Velocity seule.
Application mobile
- Contexte
- Squad iOS + Android + backend, releases mensuelles sur les stores.
- Velocity
- 28 SP en Sprints classiques, 20 SP en Sprint « release ».
- Interprétation
- La release consomme 30 % de la capacité (QA, store submission).
- Décision
- Deux Velocities moyennes : « Sprint normal » et « Sprint release ».
Infrastructure & réseau
- Contexte
- Interventions planifiées + demandes urgentes du business.
- Velocity
- 20 SP, dont 25 % de tickets non planifiés en début de Sprint.
- Interprétation
- Le contexte est proche du Kanban : le débit compte plus que la Velocity.
- Décision
- Compléter la Velocity par un Throughput et un Cycle Time.
SaaS scale-up
- Contexte
- Croissance rapide, onboarding de 2 devs sur les 3 derniers mois.
- Velocity
- Velocity qui baisse de 32 → 24 → 26 → 30.
- Interprétation
- Chute attendue liée à l'onboarding, puis remontée progressive.
- Décision
- Attendre 3 Sprints supplémentaires avant de recalibrer la moyenne.
E-commerce — pic saisonnier
- Contexte
- Freeze fonctionnel imposé de novembre à janvier.
- Velocity
- 35 SP hors freeze, 8 SP pendant le freeze.
- Interprétation
- Deux régimes très différents ; moyenner sur l'année n'a aucun sens.
- Décision
- Communiquer deux Velocities distinctes selon la période.
14. Checklist des bonnes pratiques
Cette checklist condense les pratiques observées dans les équipes qui utilisent la Velocity comme un outil, pas comme un objectif. À revoir en Sprint Retrospective quand une dérive apparaît.
Checklist Velocity — bonnes pratiques
- Conserver la même équipe— La Velocity est propre à la composition actuelle : chaque changement recalibre le repère.
- Utiliser une échelle d'estimation cohérente— Suite de Fibonacci figée, mêmes références sur plusieurs Sprints — sinon la Velocity devient un chiffre creux.
- Mesurer sur 3 à 5 Sprints— Un seul Sprint n'a pas de signification statistique ; au-delà de 5, on intègre des données obsolètes.
- Privilégier les tendances aux valeurs absolues— La direction (stable, hausse, baisse) est plus riche qu'un chiffre isolé.
- Utiliser la Velocity uniquement pour prévoir— Sprint Planning et Release Planning — jamais comme évaluation individuelle.
- Ne jamais en faire un objectif— Fixer une Velocity cible provoque immédiatement du gonflage d'estimations.
- Communiquer sous forme de fourchette— Min × 0,9 → Max × 1,05, avec la variance des derniers Sprints.
- Ajuster à la Capacity du prochain Sprint— Congés, formations, jours fériés : la Capacity réelle guide l'engagement.
- Recalibrer après un changement structurel— Turnover, refonte DoD, changement de longueur de Sprint : 2 à 3 Sprints d'observation.
- Traiter Velocity et valeur séparément— Une Velocity haute sur des items sans valeur reste un échec produit.
15. 7 questions PSM I entièrement corrigées
La Velocity revient régulièrement à la certification PSM I, souvent pour vérifier que vous savez qu'elle n'est pas définie par le Scrum Guide. Voici 7 questions typiques avec corrections détaillées et explication des mauvaises réponses.
Quelle affirmation sur la Velocity est correcte selon le Scrum Guide 2020 ?
- La Velocity est un artefact Scrum obligatoire.
- La Velocity doit être maximisée par le Scrum Master.
- La Velocity n'est pas définie dans le Scrum Guide.
- La Velocity remplace le Sprint Goal.
Pourquoi les autres propositions sont incorrectes
- A. Aucun artefact ne s'appelle Velocity. Les artefacts sont Product Backlog, Sprint Backlog et Increment.
- B. Le Scrum Master ne pilote pas de KPI de production — encore moins pour « maximiser » un chiffre.
- D. Le Sprint Goal est qualitatif (le pourquoi du Sprint). Rien à voir avec une mesure de débit.
Une équipe termine 30 SP en Sprint 1 puis 10 SP en Sprint 2. Quelle est la meilleure Velocity à utiliser pour prévoir le Sprint 3 ?
- 30 SP — le meilleur Sprint reflète le potentiel de l'équipe.
- 10 SP — il faut être conservateur.
- 20 SP — la moyenne des deux Sprints.
- Aucune Velocity fiable : 2 Sprints ne suffisent pas.
Pourquoi les autres propositions sont incorrectes
- A. Choisir le maximum crée un sur-engagement systématique.
- B. Choisir le minimum sous-utilise l'équipe et fausse le Product Backlog.
- C. Techniquement une moyenne, mais statistiquement peu significative sur 2 Sprints.
Un manager veut comparer la Velocity de deux équipes travaillant sur le même produit. Que doit-il faire ?
- Comparer directement les valeurs de Velocity.
- Normaliser les Story Points via un référentiel commun.
- Ne pas comparer — les Story Points sont relatifs à chaque équipe.
- Comparer uniquement si les équipes ont la même taille.
Pourquoi les autres propositions sont incorrectes
- A. Comparaison directe = interprétation invalide, pousse au gonflage.
- B. Techniquement possible mais coûteux et rarement utile — et ce n'est pas la bonne réponse « par défaut ».
- D. La taille n'a rien à voir : deux équipes de même taille peuvent avoir des échelles très différentes.
Un Product Backlog Item est « terminé à 90 % » à la fin du Sprint. Comment le comptez-vous dans la Velocity ?
- Pour 90 % de ses Story Points.
- Pour 100 % — l'intention comptait.
- Pour 0 SP — la règle est binaire (Done ou pas Done).
- Vous re-estimez l'item avant de compter.
Pourquoi les autres propositions sont incorrectes
- A. Compter des fractions fait « mentir » la Velocity et introduit du travail non terminé dans l'Increment.
- B. Un item non-Done ne contribue pas à un Increment potentiellement livrable.
- D. La re-estimation se fait a posteriori si l'item revient, mais ne change pas le fait qu'il compte 0 pour ce Sprint.
Que doit faire le Scrum Master si la direction impose un objectif de Velocity chiffré à l'équipe ?
- Transmettre l'objectif à l'équipe.
- Aider la direction à comprendre pourquoi c'est contre-productif.
- Négocier une Velocity intermédiaire.
- Démissionner.
Pourquoi les autres propositions sont incorrectes
- A. Relayer un objectif chiffré revient à cautionner l'anti-pattern.
- C. « Négocier » un chiffre reste un chiffre imposé — le vrai sujet est ailleurs.
- D. Ce n'est pas une réponse Scrum : le Scrum Master a un rôle de coaching à jouer.
La Velocity a chuté de 30 % au dernier Sprint. Quel événement Scrum est le plus adapté pour l'inspecter ?
- Daily Scrum.
- Sprint Planning.
- Sprint Review.
- Sprint Retrospective.
Pourquoi les autres propositions sont incorrectes
- A. Le Daily Scrum est un événement quotidien centré sur le Sprint Goal, pas sur des métriques historiques.
- B. La Sprint Planning prépare le Sprint suivant ; elle n'inspecte pas le processus passé.
- C. La Sprint Review inspecte l'Increment et le Product Backlog, pas le processus de l'équipe.
Deux Developers sont plus lents que les autres. Peut-on utiliser la Velocity pour justifier un plan d'action individuel ?
- Oui, tant que c'est fait avec bienveillance.
- Oui, mais uniquement en Sprint Retrospective.
- Non, la Velocity est une mesure d'équipe.
- Oui, si les autres Developers sont d'accord.
Pourquoi les autres propositions sont incorrectes
- A. La bienveillance n'invalide pas un anti-pattern structurel.
- B. Le cadre (Retrospective) ne change pas le fait qu'on détourne un indicateur d'équipe en évaluation individuelle.
- D. L'accord d'autres membres ne rend pas la pratique légitime.