Le mois de mai vient de se terminer et les vacances d’été arrivent, ces 2 périodes sont propices à des prises de congés (bien mérités diront certains) qui influent sur la capacité de production de l’équipe puisque le nombre de jours disponible n’est pas identique d’une itération à l’autre.

Que faire dans ce cas ?

La solution la plus simple consiste à faire une règle de 3 pour recalculer une vélocité « corrigée des variations saisonnières ». Par exemple si l’équipe dispose d’une capacité de production moyenne de 50 jours, et que pour cette itération N il n’y a eu que 42 jours de disponible, il suffit de multiplier la vélocité mesurée de N (disons 65) par 50/42, ce qui donne une vélocité corrigée de N de 77 points. C’est cette vélocité de 77 qui doit être inscrite sur le tableau de suivi de la vélocité et qui sert pour calculer la vélocité moyenne de l’équipe (utilisée pour connaitre la quantité de Product Backlog réalisable à chaque itération)

Une autre solution serait de diviser la vélocité par le nombre de jours disponible, dans notre cas, 65 / 42 = 1,55 et de comparer ce chiffre d’itérations en itérations pour savoir si l’équipe maintient une vélocité constante sur plusieurs itérations … mais je me demande s’il n’y a pas d’effet de bord ?

Qu’en pensez-vous ?

Mais le Product Backlog ne contient pas seulement des User Story puisque l’on y trouve également des exigences non fonctionnelles (souvent des demandes techniques demandées par l’équipe) et des bugs.

Alors les questions qui se posent sont :

• Est-ce que la vélocité d’une exigence non fonctionnelle ou d’un bug a un sens ?
• Doit-on estimer ces vélocités avec les mêmes pratiques ?

Si l’on revient à ce qu’est une User Story, l’aspect création de VALEUR pour l’utilisateur en est un aspect essentiel. Si l’on suit cette logique, les exigences non fonctionnelles apportent généralement de la valeur car ce sont souvent des améliorations du code qui permettent de gagner en temps de réponse, en vitesse d’exécution, en qualité du produit et en stabilité. De plus les exigences non-fonctionnelles peuvent être évaluées par la méthode du Poker Planning de la même façon que les User Story.

Compte tenu de ces éléments, il semble rationnel de comptabiliser les points des exigences non fonctionnelles dans la vélocité de l’équipe.

Pour ce qui est des bugs, il en est différemment puisque l’utilisateur n’a jamais eu besoin d’un bug et il n’y a aucune valeur ajoutée à lui livrer des bugs (sauf pour dilbert qui vend des versions +1 pour corriger les bugs, et comme le client accepte, Dilbert appelle l’équipe technique pour lui demander de rajouter des bugs).

Donc dans cette logique, les bugs ne doivent ni être évalués en points ni être comptabilisés dans la vélocité.

Une itération lors de laquelle l’équipe corrige beaucoup de bugs aura une vélocité faible, ce qui est un signal de dysfonctionnement du système. L’équipe devra alors mener un plan d’action pour réduire les bugs au minimum, comme par exemple employer les bonnes pratiques d’ingénierie venant de XP … qui est aussi une méthode

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