Scrum et les changements pendant un sprint

Quand le développement d'un nouveau projet s'effectue avec un cycle séquentiel (cycle en V ou en cascade), on évite le changement en essayant de le repousser à plus tard.

Pour cela, on essaie de définir le plus précisément possible ce qu'il faut faire en élaborant la spécification pour ensuite partir dans le développement sur cette base. Pendant le développement, les changements ne sont pas acceptés : ils sont repoussés dans la phase de maintenance.

Côté pratiques d'ingénierie, on sépare traditionnellement la gestion des exigences mise en œuvre dès le début et la gestion des changements qu'on met en branle pour la phase de maintenance.

Avec un processus agile, le changement peut être pris en compte pendant le développement.

Typiquement avec Scrum, un développement est découpé en sprints. À chaque nouveau sprint, il est possible de prendre en compte et de traiter des changements qui sont intervenus pendant le sprint précédent.

Les changements arrivent fréquemment et sont traités de façon opportuniste en fonction de leur degré d'urgence. Bien souvent il n'y a pas de règle bien définie, les interruptions peuvent être nombreuses et provoquer des perturbations.

La tâche T1 est interrompue par la tâche T2 qui est elle-même interrompue par la tâche T3. Des perturbations incessantes ont un effet nocif sur la bonne santé des équipes. De plus les interruptions fréquentes sont génératrices de changements de contexte et donc de perte de temps.

Scrum apporte une réponse à ces organisations. Pour la plupart des équipes, c'est une bonne nouvelle, à la fois pour celles qui n'acceptaient pas le changement et celles qui le pratiquaient de façon chaotique.

Cependant le passage à Scrum peut être considéré, en particulier pour ces dernières, comme trop difficile.

En effet, il existe des contextes où on ne peut pas supprimer complètement les perturbations pendant la durée du sprint. « Business first », le client sera toujours prioritaire dans des organisations qui ne peuvent pas, pour différentes raisons, dire non à une sollicitation d'un client, au moins dans la phase de transition à Scrum.

C'est ainsi qu'une équipe peut être perturbée par une démo à faire en urgence ou par un bug à corriger rapidement. Dans ces cas-là, l'approche préférable, inspirée du Kanban où la notion de flux contraint moins, permet d'accepter des changements sans attendre une fin de sprint comme avec Scrum.

Pas n'importe quand et n'importe comment cependant si on veut garder les avantages de Scrum.

Le cas, fréquent, où une seule équipe travaille sur plusieurs projets en même temps est aussi typique d'une équipe subissant des changements fréquents : le passage d'un projet à un autre s'apparente à une perturbation.

Pendant un sprint, l'équipe ne doit pas être perturbée, c'est une règle (au moins une recommandation de Scrum). Pas perturbée, cela signifie qu'on la laisse travailler pendant le sprint, selon l'objectif et le plan définis pendant la réunion de planification du sprint.

Concrètement, cela veut dire que personne n'a le droit d'ajouter du travail à la liste sur laquelle l'équipe s'est engagée sans son accord. Cela devrait aussi signifier que les ressources de l'équipe ne sont pas changées (à la baisse) pendant le sprint ou encore que du travail ne constituant pas une story, mais prenant du temps n'est pas ajouté non plus au tableau des tâches.

Diminuer les perturbations de cette façon a un effet positif. Cependant cela signifie que le traitement d'un changement est repoussé au sprint suivant. La durée des sprints peut être ajustée pour tenir compte de ce délai et réduire la gêne occasionnée.

C'est le tableau des tâches qui définit le travail à faire dans un sprint.

Dans un tableau Scrum, on trouve essentiellement des tâches associées aux stories. Elles représentent le travail détaillé à faire pour réaliser (et finir, selon la définition de ce que signifie fini) une story.

Il existe d'autres tâches, qui sont à faire pendant le sprint et qu'on ne peut pas associer à une story en particulier. Ces tâches, sans story associée, proviennent de la définition de fini pour un sprint. Par exemple, la mise à jour d'un document d'architecture, la production de rapports Sonar, le travail de test de charge, sont des tâches qu'on ne peut pas associer à une story spécifique.

Ces tâches ont une autre particularité, en plus de ne pas être associées à une story, c'est qu'elles reviennent à chaque sprint (si la définition de fini ne change pas). On peut donc les qualifier de récurrentes. Elles sont relatives à la qualité du produit. Si elles ne sont pas faites, le sprint n'est pas prolongé (évidemment, cela serait contraire à la notion de bloc de temps), la vélocité n'est pas impactée, mais c'est la qualité du produit qui en pâtit. Cela produit de la dette technique si ces tâches ne sont pas faites, soit qu'on n'y a pas pensé et elles n'apparaissent pas dans la signification de fini, soit qu'elles y sont bien, mais qu'on ne les a pas réalisées pendant le sprint.

Si on applique bien Scrum avec une signification de fini explicite, ces tâches récurrentes sont bien connues au début du sprint. Elles sont ajoutées dans le tableau des tâches au moment de la réunion de planification du sprint.

Si l'équipe travaille bien, elles seront finies à la fin du sprint et une autre instance de ces tâches sera créée lors du prochain sprint.

À la fin de la planification du sprint lorsque l'équipe s'engage, elle le fait en connaissant la durée du sprint, en connaissant les ressources (humaines) dont elle dispose, sur un périmètre défini par la liste des stories et en s'appuyant sur sa définition de ce que signifie fini.

En principe ces paramètres ne varient pas pendant le sprint. En pratique cela arrive tout de même. Pour rester dans le cadre Scrum, nous allons considérer que la durée du sprint, elle, ne peut pas changer pendant le sprint.

Si la demande de variation est à l'initiative de l'équipe, cela est un usage normal de Scrum. Une équipe qui se rend compte avant la fin du sprint qu'elle pourra en faire plus que prévu au début du sprint va demander une nouvelle story au Product Owner (ou l'inverse, d'ailleurs plus fréquent).

Si la demande est à l'initiative du Product Owner, c'est différent. Cela signifie qu'il a changé d'avis depuis la réunion de planification du sprint. Il s'est rendu compte qu'une story, qui était déjà dans le backlog de produit, est devenue plus prioritaire.

Scrum permet à une équipe de dire non. Elle peut donc refuser d'ajouter une nouvelle story demandée par le PO pendant le sprint. C'est déjà mieux que d'accepter sans condition au risque de rater le sprint.

Une approche plus subtile est parfois possible, si la demande arrive alors que l'équipe n'a pas encore commencé à travailler sur des stories du sprint. Il est alors envisageable de proposer au PO d'échanger sa nouvelle story contre l'équivalent qui serait enlevé du périmètre du sprint. Ce troc de story est facilité par une estimation préalable en points.

La signification de fini est partagée par toute l'équipe. En principe elle est définie au début du projet et peut varier légèrement à chaque sprint. Le meilleur moment pour discuter de sa mise à jour est pendant la rétrospective de sprint.

Il peut arriver que l'équipe décèle le besoin de revoir la signification de fini pendant le sprint et que cette révision entraîne du travail à faire.

Quelques exemples : la production ou la mise à jour d'un document transverse, comme celui d'architecture, la mise en place d'un script pour automatiser le déploiement…

C'est à l'équipe de décider, par exemple lors du scrum quotidien, si cette révision peut attendre le sprint suivant ou doit être entreprise au plus vite. Dans ce dernier cas, le travail à faire est considéré comme une tâche urgente, notion sur laquelle nous allons revenir.

Ce cas se produit quand du travail est demandé à un ou plusieurs membres de l'équipe, alors qu'il n'était pas prévu au début du sprint et qu'il ne s'agit pas d'une story déjà identifiée dans le backlog de produit.

Le travail demandé peut être en relation avec le produit que l'équipe développe. Cela arrive fréquemment quand l'équipe n'est pas confinée au développement, mais s'occupe aussi du support et de l'avant-vente.

Voici quelques exemples de ce qui peut arriver :

• 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é du PO ou d'utilisateurs privilégiés utilisant le résultat du sprint précédent ;
• une démo doit être faite très vite pour un (futur) client important ;
• une question posée sur le forum des utilisateurs nécessite une réponse rapide.

Parfois une ressource peut être demandée pour travailler sur quelque chose qui n'a rien à voir avec le produit développé.

Les postures possibles pour une équipe Scrum sont les suivantes :

• 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 (en général le PO) d'ajouter une entrée dans le backlog de produit. Mais ce n'est pas possible pour tous les travaux, 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. Un des risques est que ces travaux n'apparaissent pas explicitement dans le tableau des tâches.

Pour conserver deux notions essentielles de Scrum, la transparence et le timebox du sprint, il est préférable que ces travaux apparaissent explicitement dans le tableau des tâches.

L'approche recommandée est donc d'identifier les tâches vraiment urgentes et de les traiter de façon spécifique, à l'intérieur du sprint Scrum. Les événements qui ne seront pas considérés comme urgents et donc pas traités dans le sprint courant, il convient d'en faire une story qui va dans le backlog de produit.

Dans certaines circonstances, on peut parler de perturbation prévue. C'est le cas lorsqu'un événement ponctuel a lieu pendant le sprint. Cela peut-être la participation à un salon, ou une personne qui part en formation. Une perturbation c'est du travail en plus ou une ressource en moins. Si l'équipe dispose d'un calendrier visuel, l'événement y aura naturellement sa place.

À partir du moment où c'est prévu au début du sprint, cela peut être pris en compte pendant la réunion de planification. L'équipe s'engage en connaissance de cause et on ne peut plus parler de perturbation.

Un autre cas de tâche urgente concerne le travail à faire pour l'élimination d'un obstacle rencontré pendant le sprint.

Exemple : un serveur qui tombe en panne.

On suppose qu'une tâche urgente peut être dans un des trois états suivants : à faire, en cours et finie. Le plus usuel est de limiter le nombre de tâches urgentes en cours. Une limite de 1 oblige à avoir fini une tâche urgente avant d'en traiter une nouvelle, ce qui est une bonne chose.

On peut aussi limiter le nombre de tâches dans l'état à faire. Cela contraint le PO à définir les priorités ou le degré d'urgence. Si le TAF dans l'état à faire est limité à 4 et que les 4 places sont prises, le PO peut introduire une nouvelle tâche urgente, mais à condition d'en enlever une.

Le nombre de tâches urgentes est limité dans un sprint. Quel que soit leur état. Le PO ne peut plus en ajouter lorsque la limite est atteinte. La limite se discute à chaque rétrospective.

Si la limite de TAF dans l'état en cours est supérieure à 1, il peut être intéressant d'empêcher qu'une seule personne ait plusieurs tâches urgentes en cours.

Le mou permet de faire des tâches non prévues sans remettre en cause les objectifs du sprint.

Dans la boite de temps que constitue le sprint, on peut considérer que lors de la réunion de planification du sprint, une partie est allouée à la réalisation des stories, une autre aux tâches récurrentes pour satisfaire la signification de fini et qu'il faut garder du mou pour les incertitudes sur les estimations et pour les tâches urgentes.

En lissant le temps passé sur les tâches urgentes (avec une des techniques de limitation de TAF), cela revient à garder dans chaque sprint une partie du temps pour traiter l'urgence.

Les tâches n'ayant pas de points associés, à la différence des stories, elles ne contribuent pas à la vélocité. Mais comme on y passe du temps, ce temps n'est pas passé sur des stories et donc l'impact indirect est de diminuer la vélocité.

Les tâches récurrentes prennent à peu près le même temps à chaque sprint. Leur impact sur la vélocité sera donc à peu près le même pour chaque sprint. Avec l'usage fait de la vélocité, cela revient à dire que les tâches récurrentes n'ont aucune conséquence.

Les tâches urgentes peuvent varier d'un sprint à l'autre, mais la variation est limitée par le TAF.