Le suivi de la vélocité mesure la quantité de travail qu'une équipe de développement produit achève par sprint, exprimée en points d'histoire, et utilise cette moyenne historique pour prévoir la capacité de livraison future. C'est le levier principal du Product Ops pour une planification de release réaliste et la gestion des attentes des parties prenantes.
?
Comment la vélocité est-elle mesurée et que révèle-t-elle aux équipes ?
Vélocité = total des points d'histoire achevés dans un sprint. Elle n'est significative qu'en tant que moyenne mobile, généralement calculée sur les 3 à 6 derniers sprints pour lisser les valeurs aberrantes (semaines de vacances, perturbations d'équipe). Une équipe avec une vélocité moyenne de 40 points sur 6 sprints devrait planifier des engagements de sprint d'environ 35 à 40 points, la fourchette inférieure étant plus réaliste lorsque l'incertitude est élevée. La vélocité est un outil de planification au niveau de l'équipe — elle ne doit jamais être utilisée pour comparer des équipes ou évaluer la performance individuelle d'un ingénieur. Les points d'histoire sont des estimations de taille relative, pas des estimations de temps, et l'échelle de points d'une équipe n'est significative qu'en interne à cette équipe.
?
Qu'est-ce qui cause la variabilité de la vélocité et comment le Product Ops devrait-il y répondre ?
La vélocité varie naturellement de 15 à 25 % d'un sprint à l'autre en raison de facteurs normaux : changements dans la composition de l'équipe, complexité inattendue de l'implémentation technique, congés et arrêts maladie. Signaux de variabilité préoccupants nécessitant une investigation : tendance à la baisse constante sur plusieurs sprints (peut indiquer une dette technique accumulée, une culture de dérive du périmètre (scope creep) croissante, ou des problèmes de bien-être de l'équipe) ; baisses soudaines et persistantes après un changement d'équipe (le ralentissement dû à l'intégration de nouveaux membres est attendu mais devrait se rétablir en 2-3 sprints) ; inflation de la vélocité (les équipes gonflent progressivement les estimations de points d'histoire pour « atteindre » les attentes de vélocité — ce qui rend la planification dénuée de sens). Le Product Ops surveille les tendances de vélocité et signale les anomalies pour discussion lors des rétrospectives.
?
Comment la vélocité est-elle utilisée pour prévoir les dates de release ?
La prévision des dates de release avec la vélocité est une simulation de Monte Carlo, pas une simple arithmétique. L'approche Monte Carlo : créer une distribution de probabilité à partir de la distribution historique de la vélocité de l'équipe (pas seulement la moyenne), exécuter 10 000 simulations d'achèvement du backlog restant en utilisant des vélocités échantillonnées aléatoirement à partir de cette distribution, et lire les résultats de probabilité. Cela produit une prévision avec des intervalles de confiance : « Il y a 85 % de probabilité que la fonctionnalité soit livrée d'ici le Sprint 24. » C'est plus honnête que « nous livrerons au Sprint 22 » — les parties prenantes reçoivent une fourchette de probabilité réaliste plutôt qu'une estimation ponctuelle unique qui s'avère souvent fausse. Le Product Ops construit et maintient le modèle de prévision des releases, le met à jour chaque semaine et présente des prévisions basées sur des intervalles de confiance à la direction.
Défi de Connaissance
Vous maîtrisez Suivi de la Vélocité ? Essayez maintenant de deviner le mot associé de 5 lettres !
Écrivez ou utilisez le clavier