Comment gérer les bugs en scrum ?

Ecrit par << Paquet Judicaël >>

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).

board bug
board bug

 

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.

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).

Tâche bug en agile
Tâche bug en agile

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 :

Post'it de User Story
Post’it de User Story

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.

run kanban
run kanban

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.

One Reply to “Comment gérer les bugs en scrum ?”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *