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.

Commentaires

1. Le lundi 07 mars 2011, 15:33 par Olivier

Parfaitement !!!

C'est la stratégie que nous avons adopté:
- Scrum pour le projet
- KanBan pour la maintenance

Et ça fonctionne à merveille !
Olivier

2. Le lundi 07 mars 2011, 18:06 par sfui

Hello,

juste pour être bien certain de comprendre…

Pour bien distinguer le point 2 et le point 3 de ton propos, tu proposes donc de limiter le nombre de tâches urgentes dans un sprint tout en prévoyant ce nombre à l'avance ?
Ainsi, cela veut dire que si l'équipe n'a pas de tâche urgente dans ce sprint, elle fera certainement plus que ce sur quoi elle s'est engagée. C'est bien ça ?

On est d'accord que l'on fait ça dans un environnement où l'on est quasi certain d'avoir des tâches importantes (non planifiées) au cours d'un sprint ?
Cela veut dire que l'on est dans un environnement où il y a danger de "dépasser" de ce nombre de tâches. Cela veut dire qu'un un moment, il faudra tout de même apprendre à dire non ;-)

Pour ma part, j'aime bien le principe de négociation sur l'idée que toute story entamée ne peut être reportée, mais que l'on peut *remplacer* une story par autre chose ; ce qui compte est que tout le monde comprenne que l'on remplace…

Au passage, une petite question corollaire sur le *nombre* de tâches à accepter. Est-ce que le "coût" de ces tâches (en temps ou en points) n'est pas plus intéressant que le nombre ? Ou du moins, est-ce qu'il ne faut pas limiter également le "coût" d'une tâche urgente ?

Bonjour Sylvain, oui il s'agit bien de limiter les tâches urgentes en employant le mécanisme connu sous le nom de WIP en anglais (TAF chez nous). Pour définir la bonne limite, il faut essayer. Voir à ce propos le mini-livre Kanban & Scrum que nous avons traduit ou l'excellent article de Karl Scotland traduit par Fabrice.
On peut bien aussi comme tu le suggères négocier le retrait d'une story, mais j'utilise cela plutôt en échange d'une autre story. Là mon propos est différent, il s'agit de perturbations qu'on peut difficilement traiter comme des stories. L'urgence ne permet pas d'estimer en points, ni en heures d'ailleurs. C'est pourquoi il est plus réaliste de simplement compter le nombre.
3. Le vendredi 11 mars 2011, 12:02 par Nicolas

Bonjour,

Je me permets de vous renvoyer également vers cet article qui propose quelques pistes (dont la 3ème très extrème en cas de dépassement de buffer) :
http://blog.xebia.com/2011/02/28/de...

Nicolas