Évaluation d'un bug signalé par un client
Comment évaluer un bug signalé par un client : c'est le compte associé au ticket qui détermine l'ampleur du problème. Comment faire la distinction entre une correction d'une ligne et une réponse qui va accaparer tout le sprint ?
Ce n’est pas la taille du client qui pose problème. C’est le client lui-même.
Un bug signalé par un client comporte des implications que l’équipe ne peut pas cerner à partir du ticket seul. La correction technique peut se résumer à une seule ligne de code. Mais ce sont souvent les tâches connexes qui constituent l’essentiel du travail : reproduire le problème sur les données du client, rédiger un rapport d’analyse rétrospective, préparer la réponse, décider s’il convient de créditer le compte, communiquer avec les autres clients concernés. Rien de tout cela ne figure sur le ticket. Et tout cela ralentit la cadence de travail.
Évaluez deux éléments : la correction et la réactivité. La correction relève du « planning poker » classique. La réactivité est un concept peu familier aux équipes d’ingénierie et est systématiquement sous-estimée ; c’est pourquoi les bugs signalés par les clients semblent se répercuter tout au long du sprint, même lorsque le vote sur le jeu de cartes a donné un résultat faible.
Ce qui se dit dans la salle
Backend : « La correction tient en une seule ligne. »
PM : « Quel compte l’a signalé ? »
Assistance : « Leur responsable du service client demande une analyse des causes profondes d’ici vendredi. »
Question principale : « D’autres comptes sont-ils concernés ? Devons-nous leur envoyer un e-mail ? »
Question : « Pouvons-nous reproduire le problème à partir de leurs données, ou avons-nous besoin d’un fichier exporté dont les données ont été anonymisées ? »
Questions qu’il convient de se poser avant de voter
- Qui a signalé ce problème, et quels sont son ARR, son SLA ou le statut de son contrat ?
- Faut-il réaliser un RCA ou une analyse a posteriori en externe ?
- D’autres comptes sont-ils concernés, et comment peut-on le savoir ?
- Faut-il accorder un avoir, procéder à un remboursement ou prolonger la période d’essai ?
- Qui rédige la réponse destinée au client, et figure-t-elle sur ce ticket ?
- Reproduction : données du client, sauvegarde anonymisée ou données synthétiques ?
La fonction Splitting est utile : la correction correspond à un ticket, la réponse en est un autre. Les deux passent par le « planning poker » ; seul l’un d’entre eux relève de l’ingénierie.
Évaluez séparément la correction et la réponse. C’est le nom du compte qui fait que la réponse est volumineuse.
Consultez la page « Erreurs courantes au Planning Poker » pour en savoir plus sur les risques liés au vote concernant un travail dont l’équipe n’est pas responsable. Parcourez les autres exemples d’estimation réussis, ou lancez une session gratuite de Planning Poker avec les deux stories prêtes.