La gestion des bugs en scrum est souvent une question délicate dans le monde de l’agilité. Voici une liste d’astuces que je vous propose qui ont déjà fait leurs preuves.
Comme on me demande régulièrement comment gérer les bugs dans un projet en Scrum, j’ai décidé de faire un petit article sur le sujet.
Le bug découvert en plein test
Quand nous sommes en plein Sprint et que le Product Owner teste une US, il peut découvrir un bug sur la demande ; il va alors refuser de passer la demande en « Done ». Nous rappelons que le Product Owner ne testera l’US uniquement quand l’ensemble des sous-tâches techniques (petits post’it bleus) seront terminées (de la ligne 1 de l’image à la ligne 2).
Il va donc dans ce cas rajouter une sous-tâche bug (petit post’it rouge sur la 2 ème ligne) afin de notifier l’équipe du bug à corriger.
!Attention! : on ne considère en bug uniquement un comportement anormal par rapport à la description de la user-story (US). Toute demande de changement d’une chose non prévue par l’US devra faire l’objet d’une nouvelle US à part entière pour un prochain Sprint.
Quand toutes les sous-tâches bugs passent en test alors le Product Owner pourra refaire une phase de test sur l’US afin de la valider ou de l’invalider.
Bonne pratique pour gérer le bug
Quand cela est possible, voici le meilleur moyen de corriger le bug :
- le product owner (ou le testeur) explique le bug au développeur
- ils corrigent le bug ensemble (quand le bug n’est pas trop long à corriger)
- le développeur livre le bug dans l’environnement stable
- ils vérifient que le bug est corrigé
Le bug découvert plus tard
Comment le gère t’on ?
Malheureusement, malgré de nombreux tests voire lors de regression, il est indispensable de prendre en charge les nouveaux bugs. Nous allons cette fois rajouter une tâche bug qui devra être gérée si possible lors des prochains sprints (sauf évidement en cas d’urgence absolue).
Dans ce cas, le Product Owner rajoutera une tâche de type Bug qui sera traitée de la même façon qu’une US (ou tâche technique).
Vous aurez bien compris que le bug n’est pas géré de la même façon quand il est découvert lors de tests ou lorsqu’il est vu en production.
Le concept de l’Impediment
Quand un bug est à traiter en urgence (site qui ne marche plus, moyen de paiement hors d’usage), il est impossible d’attendre les prochains sprints pour gérer le bug.
On va alors ajouter ce bug dans le Sprint Backlog en plus de l’existant. On va nommer ce type de tâches des Impediment (perturbations) que l’on comptabilisera si besoin pour montrer en fin de Sprint que tout ne s’est pas déroulé comme prévu.
C’est assez triste mais j’ai vu des équipes comptabiliser entre 30 et 50% d’Impediment par Sprint ; autant dire que cela rendait le Scrum peu efficace.
Du coup j’aime bien le représenter sur les tickets afin que ce soit bien visible comme vous pouvez le voir ci-dessous avec ce post’it avec la mention [IM] pour déclarer le ticket en Impediment :
On n’enlèvera pas le point d’effort de ce type de demandes du Burndown Chart (car pas prévu en début de Sprint) mais on l’enregistrera en fin de sprint pour faire de la prédictibilité si vous en faites.
Article : Calculer la somme des complexités autorisées (prédictibilité)
On fait une équipe RUN
Quand on a trop d’Impediment, on peut envisager de sortir deux personnes de l’équipe Scrum (si elle est assez grosse) pour les faire travailler sur un kanban qui a pour but de gérer l’ensemble des bugs rencontrés ; cette technique est d’ailleurs très utile quand l’entreprise doit faire vivre du legacy.
Particularité de cette équipe RUN :
- elle participe aux cérémonies Scrum
- elle change à chaque sprint (pour ne pas avoir des gens attribués à 100% au bug)
- elle travaille en flux continue (kanban)
Le Product Owner peut même profiter de cette équipe pour faire passer les petites demandes importantes aux yeux de l’entreprise. C’est lui qui décide des priorités à traiter par cette équipe RUN.
Prédictibilité de ces bugs ?
Je vous conseille fortement de demander à vos devs d’estimer ces bugs intervenus en production afin d’avoir une meilleure prédictibilité de vos sprints.
En effet, il faut prendre la complexité (voir les jours idéaux) des bugs en compte car cela est indispensable pour gérer au mieux votre prédictibilité. Attention à ne pas faire l’erreur de ne pas estimer vos bugs comme j’ai pu le voir dans certaines équipes qui assimilaient la complexité à la valeur business.
Si vous voulez calculer l’évolution de la valeur business du produit, il faudra utiliser un autre indicateur ; voici un article qui en parle
Article : Prioriser avec les Business Value
D’ailleurs, un bug n’a aucune valeur business car c’est une anomalie repérée qui ne devrait pas exister dans le produit. On mettra donc une valeur business 0 pour chaque bug rencontré.
Un peu d’Extreme Programming dans ce monde de Scrum
Pour les petits malins, en effet l’US est déjà un élément de l’Extreme Programming mais je vais en fait parler là surtout du concept qui dit que chaque bug rencontré doit faire office d’un développement supplémentaire pour qu’on le détecte automatiquement la prochaine fois.
J’aime beaucoup cette idée car elle vient renforcer la qualité du produit. Cela implique de rajouter des sous-tâches techniques pour rajouter ce test technique qui détectera que le bug ne se reproduit plus.
Conclusion
Vous savez tout sur la gestion des bugs en Scrum. N’hésitez pas à partager en commentaires vos astuces aux autres visiteurs de ce blog.
Dans ma précédente équipe, lorsque le PO détectait un bug c’était l’US qui retournait en « Backlog sprint » et soit le bug était lié à une sous tache, alors elle revient en to do ou en wip pour correction soit on indique une sous tache supplémentaire identifiant le bug pour correction.
Effectivement si le bug mettait en évidence un trou dans la raquette et demandait une évolution une autre demande est alors créée pour le sprint suivant ou ultérieur fonction de l’impact sur le business.
Bonjour Docteur, petite question :
Dans le cas de bugs identifiés au moment du sprint (c’est à dire un bug relatif à une US), le process est le suivant dans nos équipes :
1) L’équipe crée un ticket « defect » qui est attaché à une US. Le defect passe au statut » A traiter ». Le defect n’est pas estimé.
2)L’équipe de dev intègre le defect dans sa charge de travail sur le sprint en cours.
Le problème est que nous constatons de nombreux defects (50% du temps à traiter des defects US du sprint) et cela met en risque les objectifs du sprint. Par ailleurs en terme de calcul de la vélocité cela est compliqué car nous ne pouvons pas anticiper le nombre de defects et puisqu’ils ne sont pas estimés le calcul de la vélocité devient difficile.
Quels astuces/conseils pour inclure la charge de defects dans le calcul de la vélocité de l’équipe ?
Merci
En général, je conseille toujours d’estimer les bugs quand l’équipe porte une importance aux estimations.
Cependant, il faudrait probablement surtout voir comment diminuer ce taux de bugs : mieux écrire les user-stories ? renforcer sa definition of done ?… Les astuces pour mieux estimer les bugs est pas une solution ; vous devez voir pour faire en sorte de ne plus en avoir et traiter les raisons sous-jacentes.
Bonjour
merci pour ce billet mais une des grandes questions qu’on me pose souvent est comment gérer les bugs lors de la revue de sprint?
je parle de VRAIS bugs techniques de la part des devs.
En principe selon la méthode, ils donnent lieu à de nouvelles tâches sans user points pour le sprint suivant.
Mais la grande question est la FACTURATION: comment faire comprendre au client qu’au sprint suivant il payera x % pour corriger des bugs qu’on a fait.
Considère t on que ces bugs sont à l’unique charge du prestataire ? Dans ce cas cela signifierait que le prochain sprint ne pourra commencer qu’une fois les bugs corrigés
merci pour vos réponses
Cyril
Bonjour cyril,
Les bugs techniques doivent être géré en temps réel si possible. Il est de loin préférable parfois d’arrêter d’avancer sur un projet et consolider le produit pour ne plus avoir de bugs… mais pas toujours accepté par les décideurs.
Qu’appelles tu des user point ? Tu parles des points d’effort ? Ce n’est pas du scrum mais une adaptation que vous faites.
En effet, si vous avez fait des bugs, il faut se poser et prendre des décisions fortes pour que la situation ne se reproduise pas. Tout ce qui est livré au client doit être sans bug et si il y en a, vous avez un soucis dans le développement, les tests ou l’écriture des user stories. Il faut impérativement le faire de toute urgence car sinon vous accumulerez de plus ne plus de bugs. Malheureusement, il faudra communiquer à ton client en expliquant que le contexte global du projet a amené à cette situation ; mais il faut corriger le tir. Le problème ne vient pas forcément de l’équipe de développement.
Pour la prise ne charge des bugs, la question ne devrait pas se poser. Cela est un problème qui vient probablement de la relation que vous avez avec le client. Sur le coup, je ne peux pas te répondre, cela dépend du contrat que vous avez avec votre client et de cette relation entre lui et vous.
Mais le problème est ailleurs : pourquoi il y a des bugs et à priori un certain nombre ? Comment faire pour que cela ne se reproduise pas ? Comment améliorer le développement et toute la chaine autour ?
Bonjour et merci d’avoir pris le temps de répondre.
Je n’arrive pas à comprendre qu’on puisse générer 0 bug.
1e cas: Je ne parle pas de bugs qui rendre une story non fonctionnelle mais généralement de cas pas forcément anticipé ou effet de bord qui fait planter une fonction déjà en place depuis un certain temps mais qui doit être retouchée suite à une modif du code ailleurs.
Au final on livre un sprint avec des fonctions et le client nous alerte du bug sur une autre fonction.
Dans ce cas la relation contractuelle couvre la résolution du bug et lors du sprint suivant, si c’est une priorité du client, on corrige le bug engendré
2eme cas: on n’arrive pas à fournir dans le sprint une fonction 100% debugée car le travail s’avère plus complexe que prévu. Dans ce cas, la finition du travail se fait elle en dehors du sprint sans surfacturation ou reporte t on les heures à passer pour terminer sur le sprint suivant?
merci
cyril
Bonjour,
1/
Aujourd’hui il y a des technique de codages, d’intégration continuent de plus en plus complètes, de vérificateurs et de pratiques qui permettent de ne plus poster le moindre bug en production. Cela a un coût mais qui s’avère payant dans le futur. Sur les très anciennes structures techniques, c’est parfois quasiment impossible de pouvoir mettre ces choses en place mais les entreprises paient alors très cher le fait de ne jamais refaire (après il y a des contextes qui rendent la refonte ultra complexe et couteuse).
Après le 0 bug est même dans les meilleurs contextes très difficile à atteindre mais l’effort d’approcher du zéro devient vite gagnant…
J’ai vu trop d’entreprises voire ces évolutions comme des couts et qui aujourd’hui ont des équipes qui passent plus de 60% de leur temps à gérer le Legacy…. Un coût incalculable et qui finit un jour au l’autre à faire très mal à l’entreprise.
Le problème que tu cites est souvent lié à manque d’investissement dans la qualité technique (je parle pas de mauvais programmeurs mais d’un contexte global) qui amène à ce type de situation. Il y a des entreprises qui n’ont aucun bug sur leurs applications à ce jour et qui ne vivent jamais ce cas que tu cites.
2/ Il n’y a jamais de « hors sprint » en scrum. Un sprint se termine pour en ouvrir un nouveau.Le fait de devoir faire du reporting du temps passé pour chaque tache est de base une mauvais pratique qui n’apporte rien… Votre client doit travailler avec vous sous un contrat de confiance. Alors évidemment cela vous ait probablement imposé mais un coach agile travaille en général pour effacer ce type de pratiques coûteuses et qui n’apportent que des problèmes. Si une tache n’est pas terminée, on décide en équipe si elle doit être continuée lors du prochain sprint.
Il sera très difficile de te conseiller par rapport à ta question car selon le contexte autour, mes conseils peuvent être très ddifférents