Le coût de correction d’un bug ne devrait pas être l’élément essentiel de décision concernant sa réalisation ou non. D’autant qu’en se focalisant d'abord sur l’estimation du coût de correction on va solliciter l’équipe, interrompre son travail, créer du changement de contexte, et donc lui faire perdre son efficacité. Amener ces questions sans filtre préalable, donc plus fréquemment, accentuera ces conséquences.
C’est d’abord la question “Combien ça coûte de NE PAS corriger le problème?” qui devrait être posée. Autrement dit, quel est le niveau d’impact du bug? L'évaluation de l’impact et la planification de la correction devrait s’appuyer sur des règles claires et pourrait se résumer idéalement à 3 options :
Impact critique => à corriger maintenant (devient instantanément la plus haute priorité de l'équipe - devant le sprint en cours si Scrum)
Impact majeur => à corriger plus tard (reporté jusqu’à la prochaine séance de planification - par exemple dans le prochain sprint si Scrum)
Impact mineur => ne pas corriger, seulement documenter (ajouté au backlog)
(Reste à chacun à définir ce qui caractérise les différents niveaux d’impact…)
Si le fonctionnement est clarifié l’équipe peut alors s’auto-organiser pour répondre de la meilleure de manière et le plus efficacement possible.