La vélocité est souvent un indicateur mal utilisé  sur des projets Agile. Il est souvent confondu avec le temps consommé sur un sprint et est utilisé par le management pour contrôler la productivité des équipes Scrum. L’objectif de cet article est de comprendre la notion de vélocité et de l’utiliser correctement sur vos projets.

Calcul de la vélocité

Tout d’abord, comprenons le calcul de la vélocité. Au niveau d’une équipe Scrum, il s’agit de la somme des points des PBIs (Product Backlog Items) Done ✅ à l’issue d’un Sprint. Elle est représentée la plupart du temps sous forme d’histogramme permettant de visualiser l’évolution du nombre de points au fil des sprints. Au niveau d’un programme en Agile @ Scale de type SAFe, la vélocité pourra être consolidée au niveau d’un Release Train.

D’où viennent ces points

En Scrum, l’estimation des PBIs est confiée à l’équipe de développement (et uniquement à l’équipe de développement !). Lors des sessions de Product Backlog Refinement, l’équipe estime l’effort du PBIs en points. Cet indicateur est totalement empirique. L’équipe suit en général une suite de Fibonacci pour le quantifier. Des outils simples à mettre en place comme le T-Shirt sizing ou le planning poker sont très efficaces pour lever tout doute sur la complexité du PBI à livrer. Durant ces sessions, beaucoup de questions remontent de l’équipe vers le product owner pour clarifier les Acceptance Criterias du PBI afin de calculer l’effort le plus juste possible.La vélocité planifiée dans le Sprint est déterminé à l’issue du Sprint planning. Il s’agit de la somme des points pour les PBI sur lesquels l’équipe s’est engagée. Il s’agit d’un indicateur de planification ou de Forecast.

Un indicateur empirique

En suivant les concepts de Lean, l’équipe doit chercher à s’auto-évaluer, mesurer de manière factuelle son efficacité et s’améliorer de manière continue. La vélocité est un indicateur propre à chaque équipe. Il ne peut être comparé d’une équipe à l’autre. C’est un indicateur défini par l’équipe pour servir l’équipe ! La vélocité évolue tout au long du projet à chaque Sprint. Les variations peuvent s’expliquer par :

  • Une variation de capacité de l’équipe : Par exemple, un développeur en vacances
  • Des impediments bloquant l’évolution de  l’équipe dans l’achèvement du Sprint Backlog
  • Un manque de rigueur dans le refinement du Backlog
  • Un manque de rigueur dans l’application de Scrum en général.

Lors de la Sprint Rétrospective, l’ensemble de l’équipe Scrum (Product Owner, Scrum Master et Dev Team) peuvent analyser leur propre vélocité pour comprendre les potentiels problèmes et trouver un plan d’action pour les résoudre.

Une vélocité stable, un bon indicateur

La vélocité met en général 3 à 5 Sprints à se stabiliser suivant les équipes. Une fois stable, elle devient un excellent outil de prédiction. Une vélocité stable sur plusieurs sprints indique la charge nominale de l’équipe. Il ne faut pas chercher à l’augmenter à tout prix au risque de compromettre la qualité de l’incrément.

Les dérives du suivi de la vélocité

Lorsque la vélocité est monitorée par le management et prise en compte comme un indicateur de performance cela conduit à de nombreuses dérivent qui nuisent au respect des valeurs de Scrum et peuvent impacted considérablement la productivité du projet.

  • Augmenter la vélocité à tout prix : L’équipe peut très bien décider de le faire mais ne doit pas se le faire imposer. Si c’est la cas, la nature humaine est bien faite et les développeurs vont automatiquement augmenter leurs estimés sur les PBIs. Par conséquent la vélocité sera faussée et deviendra inutile. Dans d’autres cas, l’équipe s’engagera au-delà de sa capacité et ne délivrera pas le bon niveau de qualité et n’aura plus un rythme soutenable.
  • La concurrence entre les équipes : Tenter de comparer la vélocité de plusieurs équipes Scrum ne fait pas de sens et peut casser la dynamique collaborative du projet. Cela est souvent vu sur des programmes agiles à l’échelle. Il peut éventuellement être intéressant d’avoir une idée de la vélocité consolidée de l’ensemble des équipes mais pas d’analyser les différences entre elles.

Conclusion

En résumé, la vélocité est un indicateur de prédiction. Pour l’équipe Scrum, il permet de pouvoir s’engager sur le Sprint Backlog de manière cohérente. Il permet aussi d’analyser de potentiels disfonctionnements. Au niveau Programme, cet indicateur pourra être utilisé à des fins de planification pour projeter les fonctionnalités à venir sur les prochains sprints.