De mon point de vue, la vélocité est une mesure de capacité de production qui est lié à une équipe et une seule dans le contexte spécifique d’un projet. Au grand damme des managers classiques, il n’est malheureusement pas possible de comparer les vélocités entre équipes pour savoir si l’une est meilleure que l’autre et si un sous-traitant travaille mieux qu’un autre.

Lorsque la vélocité est calculée, et je recommande fortement de le faire, je l’utilise principalement de 3 façons différentes (liste non exhaustive bien entendu) :

• Permettre la planification Agile : C’est effectivement un élément primordial pour estimer la durée de réalisation d’un ensemble de user story et proposer un plan de release (qui n’est pas un engagement mais une estimation). Ce n’est pas forcément nécessaire sur tous les projets, mais c’est souvent le cas.
• S’engager sur une itération en connaissance de cause : Lorsque vous connaissez votre vélocité, vous savez sur quoi il est raisonnable de s’engager à réaliser lors d’une itération. Sur les petits projets (2 personnes par exemple) vous savez immédiatement si une user story est trop grosse car souvent son nombre de points est supérieur à votre vélocité, et comme vous serez dans l’incapacité de l’implémenter en une seule itération, il est donc nécessaire de la découper.
• Etre alerté rapidement en mode établi : Si la vélocité d’une équipe baisse, c’est qu’il s’est passé quelque chose et vous pouvez chercher le problème et proposer des solutions. Cela est vrai que l’équipe soit interne ou externe (sous-traitance). Si la vélocité d’une équipe augmente … c’est probablement parcequ’une action d’amélioration a été conduite.

Comme disait Jeff Sutherland à Toronto : « Lorsque je rencontre le PDG d’une entreprise, je lui demande s’il connait les vélocités de ses équipes. S’il ne peut répondre, alors je lui demande comment il peut avoir confiance dans la tenue des objectifs annoncés par son entreprise »

Bon d’accord, tout le monde ne s’appelle pas Mr Sutherland