Évaluation d'un bug signalé par un client
Comment évaluer un bug signalé par un client : c'est le contenu du ticket qui détermine son ampleur. Comment faire la distinction entre une correction d'une ligne et une réponse qui va accaparer tout le sprint.
Ce n’est pas le produit qui est trop grand. C’est le client qui est trop grand.
Un bug signalé par un client comporte une portée que l’équipe ne peut pas appréhender à partir du ticket seul. La correction technique peut se résumer à une seule ligne de code. Mais le travail qui l’entoure — 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 — représente souvent l’essentiel de la tâche. Rien de tout cela ne figure sur le ticket. Tout cela ralentit la cadence.
Évaluez deux éléments : la correction et la réaction. La correction correspond au « planning poker » classique. La réaction, en revanche, est peu familière aux équipes d’ingénierie et est systématiquement sous-estimée — ce qui explique pourquoi les bugs signalés par les clients semblent s’étaler sur toute la durée 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 qu’une analyse des causes profondes soit réalisée d’ici vendredi. »
Responsable : « 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 fait l’objet d’un ticket, la réponse d’un autre. Les deux passent par le « planning poker » ; seul l’un d’entre eux relève du domaine de l’ingénierie.
Veuillez estimer séparément le coût de la réparation et celui de l’intervention. C’est le nom du compte qui fait grimper le coût de l’intervention.
Consultez la page Erreurs courantes au Planning Poker pour en savoir plus sur les risques liés au vote concernant des tâches qui ne relèvent pas de la responsabilité de l’équipe. Parcourez les autres exemples d’estimation réussis, ou lancez une session gratuite de Planning Poker avec les deux stories prêtes.