De quoi s'agit-il?

A la fin d'une itération, l'équipe additionne les estimations associées aux user stories qui ont été terminées au cours de cette itération. Ce total est appelé vélocité.

Une fois connue, la vélocité peut être utilisée pour valider ou réviser la planification de l'ensemble du projet, en partant du principe que la vélocité lors de futures itérations sera approximativement égale à la dernière vélocité constatée.

Exemple: une équipe entame une itération, prévoyant de terminer les stories suivantes: A, estimée à 2 points; B, estimée à 2 points; C, estimée à 3 points. A la fin de l'itération, les stories A et B sont terminées à 100% mais C n'est terminée qu'à 80%.

Une équipe Agile ne reconnait que deux niveaux de complétion: 0% ou 100%. Par conséquent C n'est pas comptabilisée, et la vélocité de l'itération est de 4 points. Supposons que la totalité des stories du projet représente 40 points; on prévoit donc une durée totale du projet équivalente à 10 itérations.

L'itération suivante, l'équipe devrait ne prévoir qu'un lot de stories équivalent à 4 points, afin d'éviter de retomber dans le travers que constitue une story terminée à 80%. La vélocité fonctionne ainsi comme une soupape permettant de faire retomber la pression lorsque l'équipe rencontre des difficultés à tenir ses engagements. (Si la story C est complétée au début de l'itération suivante, les 3 points correspondants pourront être comptabilisés dans la vélocité de cette dernière. La vélocité de l'équipe va donc "naturellement" remonter.)

Erreurs courantes

Cette définition a plusieurs conséquences importantes:

• la vélocité est une constatation, une mesure à postériori, et non un budget ou une prévision; parler de "fixer une vélocité" est un contresens

• on parle de la vélocité d'une équipe uniquement, en aucun cas de vélocité individuelle; cela n'aurait pas de sens, une équipe étant conçue précisément comme un ensemble plus performant que la somme de ses individus

• on ne peut pas directement comparer la vélocité de deux équipes différentes, puisque ces équipes peuvent avoir émis leurs estimations sur des bases différentes

• pour que la vélocité permette la prévision d'une date de fin du projet, il est impératif que l'ensemble des user stories que comprend le projet soient estimées de façon cohérente; il existe deux manières d'y parvenir:

  • estimer la totalité des user stories très tôt dans le projet (avant ou pendant les premières itérations)

  • utiliser une technique d'estimations relatives pour s'assurer que les estimations tardives sont émises sur la même base que celles émises en début de projet

Origines

• le terme de "vélocité" provient d'Extreme Programming, où il apparaît assez tardivement, remplaçant le terme "load factor" dont la définition est jugée trop complexe (milieu de l'année 2000)

• la définition canonique apparaît dans Planning Extreme Programming de Beck et Fowler (2001)

• le terme est ensuite adopté par la communauté Scrum à partir de 2002