Scrum et les tâches urgentes

Pendant un sprint, une équipe Scrum ne devrait pas, en principe, être perturbée. Cependant il arrive que des perturbations correspondent à des travaux urgents qui ne peuvent pas attendre, alors que faire ?

Lors de la réunion de planification du sprint, l’équipe, après avoir identifié les tâches à faire pendant le sprint, s’engage sur un périmètre (constitué par une liste de stories) et sur la qualité avec laquelle elle va le produire (défini par la signification de fini).

Une tâche urgente constitue du travail demandé à un ou plusieurs membres de l’équipe, qui n’était pas prévu au début du sprint. Pas prévu, cela veut dire que c’est du travail qui n’est pas en relation avec la liste des stories sélectionnées pour ce sprint, ni découlant de la définition de fini.

Le travail demandé -en urgence- peut être en relation avec le produit que l’équipe développe. Cela arrive fréquemment quand l’équipe ne s’occupe pas que du développement, mais aussi du support et de l’avant-vente.
Voici quelques exemples de ce qu’on peut considérer comme des perturbations dans un sprint :

  • Un défaut (bug) a été trouvé sur le produit, qu’il soit en production (ce qui fait augmenter le degré d’urgence) ou pas
  • Du feedback est remonté par le Product Owner ou par des utilisateurs privilégiés portant sur le produit partiel, résultat du sprint précédent
  • Un commercial (ou un chef) demande à l’équipe de préparer une démo très vite pour un (futur) client important
  • Une question posée sur le forum des utilisateurs nécessite une réponse rapide. Parfois un membre de l’équipe peut être appelé pour travailler sur quelque chose qui n’a rien à voir avec le produit développé : un ancien projet sur lequel il a travaillé par exemple.

Lorsqu’une tâche urgente se présente, une équipe Scrum peut prendre une de ces positions :

  • Dire non. Il est probable que certains des travaux demandés peuvent attendre le sprint suivant. La solution est alors pour les demandeurs de ces travaux d’ajouter une entrée dans le backlog de produit, qui sera examiné par le Product Owner. Mais ce n’est pas possible pour tous les travaux d’attendre le sprint suivant, certains ayant un véritable caractère d’urgence.
  • Dire oui. Le problème est que cela va avoir un impact sur l’engagement de l’équipe du début de sprint, puisqu’elle va passer du temps sur ces tâches non prévues. Si cela n’est pas contrôlé on en revient au chaos des changements permanents. Comme ces travaux n’apparaissent pas explicitement dans le tableau des tâches, on court le risque qu’ils sortent de la responsabilité de l’équipe et nuisent à son auto-organisation.
  • Accepter, mais en limitant le nombre de tâches urgentes. Les tâches urgentes apparaissent explicitement et ne peuvent être ajoutées que si la limite n’est pas atteinte. Cela revient à introduire un peu de Kanban dans Scrum, à faire du ScrumBan.

C’est le sujet que nous aborderons, avec Kanban & Scrum, tirer le meilleur des 2, dans la présentation que nous ferons, avec Antoine et Fabrice, au Scrum Day du 31 mars.