Lorsqu'on considère les bugs au même titre que des nouvelles fonctionnalités, notamment en leur "attribuant" des Story Points, on crée une illusion de livraison de valeur.
On se concentre alors sur le maintien, même artificiel, de la vélocité.
Or, corriger un bug ne fait que restaurer la valeur attendue qui n'a pas été délivrée initialement par la fonctionnalité.
Pire, vu de l'utilisateur ou du client, on peut considérer que si une nouvelle fonctionnalité apporte bien une valeur visible positive au produit, un bug lui apporte une valeur visible négative ! Car qui aime trouver un bug dans une application ? Est-ce que cela donne une bonne image du produit, ou cela fait-il du mal à sa réputation ?
C'est pourquoi la valeur intrinsèque d'une correction de bug devrait être nulle afin de réajuster progressivement la véritable vélocité de l'équipe - lissée sur quelques sprints.
Hello! Super travail, merci pour ce blog ! Par contre (mode 1er degré - ON), pour moi la vélocité n'est pas une mesure de la valeur, mais une mesure permettant plus de prédictibilité (court terme) à l'équipe sur ce qu'elle peut délivrer. La mesure de la valeur délivrée doit se faire en complément de la mesure de la vélocité et les deux doivent servir à prendre les bonnes décisions, notamment ce qu'on veut mettre dans le(s) prochain(s) sprint(s), pour définir le bon équilibre entre apport de valeur, correction de bugs, de dette technique, veille, discovery, etc. Après on peut aussi différencier les mesures de vélocité : suivre séparément le nombre de story points livrés sur les stories et sur les bugs.…