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