Il est tentant de comparer les vélocités de deux équipes, ou de faire un prorata par développeur. Eh bien, ça ne fonctionne pas : les estimations de l’équipe A ne sont pas celles de l’équipe B.

Le concept en bref

La vélocité, c’est « l’effort » moyen qu’une équipe est capable de réaliser sur une période donnée (une quantité de sprints, par exemple). Cet effort s’exprime généralement en Story Points.

Pourquoi c’est important

• Prévoir la charge d’un sprint — en additionnant les Story Points, on sait quelle quantité de tickets peut raisonnablement entrer dans un sprint
• Planifier / faire un forecast — la vélocité permet de tenter d’estimer quand une fonctionnalité sera terminée, en divisant son coût total (en SP) par la vélocité moyenne de l’équipe

Comment faire

Le calcul de base : on additionne, sprint après sprint, les Story Points des tickets terminés (qui répondent à la Definition of Done), puis on fait la moyenne sur plusieurs sprints.

Sur quelle période calculer ? On pourrait penser que plus la période de référence est longue, plus la mesure est fiable — ce n’est pas le cas. La vélocité varie dans le temps : montée en compétence de l’équipe, meilleure rédaction des tickets, meilleure compréhension mutuelle… L’information est considérée comme fiable après 3 à 5 sprints, mais reste peu adaptée à un forecast à long terme : plus le calcul se projette loin dans le futur, moins il a de valeur.

Exemple concret

Calcul de la vélocité sur 5 sprints

Sprint	Points brûlés
Sprint 7	25
Sprint 8	11
Sprint 9	37
Sprint 10	24
Sprint 11	26

Total sur 5 sprints : 123 points → vélocité moyenne : 24,6 points/sprint

Utiliser cette vélocité pour un forecast

Une fonctionnalité dont les tickets totalisent 94 Story Points, avec une vélocité de 24,6 :

94 / 24,6 = 3,82 → il faudra environ 4 sprints pour la livrer.

Pièges & limites

• Jours de maladie / congé — moins de temps de développement disponible, donc moins de SP brûlés. Effet d’autant plus fort que l’équipe est petite (100 % d’impact sur une équipe d’1 développeur). « Ça se lisse sur l’année » n’est vrai qu’en partie
• Changements dans l’équipe — si l’équipe n’est pas stable, la vélocité mesurée n’a plus aucune fiabilité. Un nouvel arrivant mobilise du temps d’intégration (la vélocité remonte ensuite, sinon il faut se poser des questions) ; un départ réduit mécaniquement la force de travail disponible
• Spécialisation des membres — un sprint avec plus de tickets front-end que back peut laisser un spécialiste back-end sans ticket dans son domaine (bon moment pour de la dette technique ou de l’analyse, cela dit)
• Ne jamais comparer les vélocités entre équipes — ni faire un prorata par développeur : les estimations d’une équipe A n’ont aucune équivalence avec celles d’une équipe B