En tant que Product Owner / Product Manager, vous êtes vous déjà retrouvés dans la situation de devoir répondre aux questions suivantes : Est-ce possible de corriger ce bug dans la journée ? Quel est le degré de criticité de ce bug ? Comment remonter un bug à l’équipe Product ? Parmi tous les bugs remontés, lesquels doivent être priorisés dans le prochain sprint ?
Écrit par
Benoit Morane
Published on
23 Février 2023
En tant que Product Owner, la correction d’un bug ainsi que sa priorisation est une tâche à part entière et ne doit pas être négligée sous peine d’impacter la qualité du produit, la satisfaction des utilisateurs ou le lancement de nouvelles fonctionnalités.
Avant de prioriser la correction d’un bug, il est essentiel de pouvoir le reproduire. Un tips actionable rapidement est de partager un template de ticket de bug pour permettre de guider les différentes personnes susceptibles de remonter des bugs d’y mentionner toutes les informations nécessaires à sa reproduction. Concrètement il faut à minima les informations suivantes :
Device
Navigateur
Comportement observé avec les étapes précises faites par l’utilisateur
Comportement attendu
Screenshot ou enregistrement vidéo
Puis il faut se poser les bonnes questions :
Est-ce que c’est un client / utilisateur final directement ou quelqu'un d’interne qui a remonté le bug ? Est ce que c’est un client particulier / prioritaire ?
Combien de clients sont impactés ?
Est-ce que vous avez des engagements clients en termes de SLA sur les temps de résolution des bugs ?
Y a t’il un navigateur ou device particulier sur lequel le bug apparaît ? Si oui celui-ci est-il beaucoup utilisé ? (par exemple si un bug est remonté sur Safari qui représente seulement 1% du traffic, doit-il être corrigé ? Théoriquement cette question a dû être traitée dans la definition of done qui inclut la liste des navigateurs ou devices maintenus / recommandés)
Est ce que le bug impacte une feature très utilisée ou non ?
Est-ce qu’on anticipe une grosse complexité sur la correction de ce bug ?
On va ensuite classifier le bug selon son importance.
Le Product Owner établit alors un ordre de priorisation avec une définition claire de chaque priorité. Un exemple d’ordre de priorisation simple peut être :
P1 : Bug critique impactant l’environnement de production et le fonctionnement du produit ou bug impactant un client majeur
P2 : Bug important impactant l’environnement de production mais pas le fonctionnement du produit
P3 : Bug mineur n’empêchant pas le bon fonctionnement du produit
Won't do : Bug qui ne sera pas corrigé
Selon votre environnement, vous pouvez ajouter des critères pour différencier les P1, P2 et P3.
Une fois les bugs priorisés, le Product Owner les ajoute dans son backlog.
P1 : Le bug doit être corrigé ASAP et rentre donc dans le sprint en cours; cela a pour impact la dépriorisation d’autres tickets priorisés initialement dans le sprint, pour être cohérents par rapport à la capacité initiale du sprint
P2 : Le bug sera embarqué lors du prochain sprint
P3 : Le bug rentre dans le backlog et sera corrigé lors d’un sprint futur
Si vous avez de nombreux bugs P2 et P3, une bonne pratique pour éviter d’accumuler de la dette fonctionnelle est de prévoir entre 10% et 30% de la capacité de chaque sprint à la correction de bugs.
En conclusion :
Il est essentiel de passer du temps à traiter les bugs et à les prioriser sous peine d’impacter les utilisateurs et les nouvelles features à lancer
Un ordre de priorisation doit être clairement défini afin de savoir quand ce bug doit être traité
Un bug P3 qui n'est pas pris au bout de 4 sprints peut être supprimé car il ne sera jamais priorisé
