La vélocité des bugs

bugs2Scrum définit la vélocité de l’équipe pour une itération comme étant la somme des points des User Story terminées à la fin de l’itération. L’évaluation de la valeur en points d’une User Story est souvent faite par l’équipe à l’aide du Planning Poker de façon autonome, il est donc vain de chercher à comparer des vélocités entre équipe (Cf. Du bon usage de la vélocité). Cette vélocité est un élément indispensable de la planification agile.

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 🙂

4 réflexions sur « La vélocité des bugs »

  1. Bonsoir Alex,
    Je comprends que tu mets les bugs dans le backlog de produit mais que tu ne les estimes pas (lors du planning poker)comme les autres éléments du backlog : puisque tu ne les fais pas rentrer dans la vélocité pas la peine de les estimer.
    J’ai une position différente. Les bugs ont un coût donc il me paraît normal de l’estimer comme les autres éléments. L’argument « pas de valeur » ne justifie pas qu’ils n’ont pas de coût. Puisqu’un bug a un coût, je suis partisan de le faire apparaître, en distinguant dans la vélocité la partie bugs.
    D’autre part, je ne suis pas d’accord, un bug a un rapport avec la valeur : il diminue (ou supprime) la valeur de story sur laquelle il porte. Imaginons une story avec une valeur (pas un coût) de 100, un bug sur cette story fera que sa valeur est peut-être 0 si le bug est critique, 80 si le bug est mineur. Un bug a de la valeur négative.
    Pour les exigences non fonctionnelles, je pense que certaines ne peuvent pas aller dans le backlog. Par exemple : l’application devra fonctionner les navigateurs 1, 2 et 3. Impossible de le finir en une itération. Cela va plutôt dans la définition de fini.

  2. Comptabiliser la vélocité des bugs indépendamment me semble acceptable car le dysfonctionnement (beaucoup de bugs) sera visible, mais il y a également le risque de voir l’équipe, ou le management, masquer la réalité en ne regardant que la vélocité globale.

    Pour ce qui est du fait qu’un bug change la valeur d’une US … je ne partage pas du tout ton point de vue. La méthode est parfaitement claire sur ce point pour dire que la comptabilisation des points d’un US est binaire (tout ou rien). Ce que tu proposes revient à accepter des % de terminé … très dangereux !

  3. Non, ce que je dis ne remet pas en question ce comptage binaire de vélocité. Tu m’as mal compris.
    Mais il y a des bugs qui viennent après qu’on ait accepté une story ou simplement sur des choses qui ont été développées avant d’être agile et de compter les points.

  4. Ce qui ne me plait pas, moi, dans la comptabilisation et la valorisation aussi fine des bugs, c’est que l’on se met en mode « pur correctif ».
    Ce n’est pas de l’amélioration continue mais de l’adaptation au coup par coup.
    Dans ces conditions, qu’est-ce qui va permettre de valoriser des tâches de refactoring, de mise en application de patterns de codage, de faire du TDD, etc … ?
    Haro sur le fonctionnel et on corrigera au fur et à mesure de l’apparition des bugs ?? Trop tard, la dette technique est là, et c’est d’autant plus vrai quand il y a un « passif » !!

    La question est : s’agit-il d’éliminer les bugs ou de les empêcher de survenir ?

    Donc : OUI pour les pratiques XP et oui, c’est effectivement intéressant : ne pas valoriser les bugs mais considérer qu’ils vont diminuer la vélocité de l’équipe, une espèce de « punition », de « dette », pour les avoir laissé passé. Le tout avec un plan d’action pour s’améliorer, bien sûr.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *