Des spikes dans les sprints

Mercredi, lors de la réunion de planification du sprint que j'animais, nous avons inclus dans le sprint plusieurs spikes. On utilise un spike pour mener des travaux d'étude, d'exploration technique d'un élément (user story) du backlog.

Cela revient à décomposer cet élément en 2 parties[1] :

  • le spike proprement dit, qui est fait au sprint n
  • le développement de l'élément qui sera inclus dans le sprint n+1 (ou pas selon les résultats du spike)

Quand l'utiliser ?

  • Le spike est utilisé quand on ne sait pas estimer une user story. En général, si on ne sait pas l'estimer, c'est qu'on ne connaît pas de solution technique pour cette story.
  • Le spike peut aussi être utilisé pour étudier plusieurs solutions différentes. Dans notre produit, nous avons à intégrer des données d'un décisionnel et il y a plusieurs possibilités pour le faire, le spike va permettre de les étudier.
  • Enfin le spike peut aussi être utilisé quand la story est très grosse et qu'elle ne peut pas être finie en un seul sprint. Dans notre cas, c'était le cas pour la story portant sur la migration des données de l'ancienne application dans la nouvelle. A noter que si la story n'a pas été décomposée avant, c'est probablement parce que la solution technique n'est pas connue ou mal maîtrisée.

Le spike sert à approfondir le comment (la conception), pas le quoi, qui est du ressort du product owner. Donc si on ne sait pas estimer, il faut savoir si c'est par manque de précisons sur le quoi ou par méconnaissance du comment avant de décider de faire un spike.

Quel est le résultat d'un spike ?

On fait un spike pour comprendre comment développer une story. A la fin du sprint incluant un spike, on devrait :

  • avoir défini une solution
  • être capable d'estimer le coût de développement, pour aider le product owner à décider quoi faire de cette story.

Il arrive aussi que le spike amène à décomposer la story initiale en plusieurs autres, plus petites.

Quel est le temps consacré à un spike ?

Un spike est normalement limité à une durée fixée (principe du timeboxing) au début du sprint. La pratique recommandée veut qu'on ne passe pas plus d'une journée de travail (8 heures) sur un spike.

Un nom en français pour spike ?

En anglais un spike est une pointe. En français on pourrait dire une pique, qu'en pensez-vous ?

Notes

[1] c'est donc un autre cas où une exigence/story n'est pas finie en une seule itération après le cas de l'utilisabilité dont j'ai parlé récemment

Commentaires

1. Le lundi 17 mars 2008, 13:28 par Alix

Bonjour,
J'ai une question à propos d'une demande comme une data migration:
Le fait de faire un 'spike' (nb: c'était pas le nom du vampire dans buffy ? :-) sur une sujet qui doit etre important pour le projet remet t'il en cause la suite du projet ? Je m'explique : si la data migration n'est pas possible, le produit n'est peut etre pas utilisable mee avec les meilleures fonctionnalitées du monde, donc dans les priorités métier la mise en place des données doit etre en top priorité et tant que ce sujet n'est pas réglé il est inutile de continuer à produire (pilotage par les risques, respect des regles de base du Lean qui est de ne pas produire inutilement). Dans ce cas que fait l'équipe ? tout le monde cherche la solution sur le point bloquant ou fait on une entorse à la regle en supposant que le risque de ne pas etre capable de faire la migration sera resolu plus tard ?

Merci.

Un spike peut remettre en cause la prise en compte d'une fonctionnalité, mais pas dans l'exemple que j'ai pris : la migration de données est obligatoire. Mais elle est toujours possible : il a même été envisagé de prendre un stagiaire pour rentrer les données ! Le risque de ne pas être capable de faire la migration est négligeable. Le spike va permettre de trouver la solution la plus appropriée. Si c'était un risque majeur, vous avez raison, il faudrait le réduire au plus vite. Quant au nom du vampire dans buffy, là je ne sais pas. Pas vu la série.
2. Le lundi 17 mars 2008, 19:00 par Alix

ok merci.
Pour la série vous n'avez rien loupé : -)

3. Le mardi 18 mars 2008, 17:50 par sylvain

Bonjour,

dans un monde malheureusement non idéal où, au moment de la réunion de planification on s'apperçoit que l'on ne sait pas chiffrer une histoire de priorité très importante et que l'on décide de faire un spike. Vu qu'un spike est de l'ordre d'une journée de travail, peut-on imaginer que l'on reprenne la planification de la même itération en intégrant immédiatement le résultat du spike ?

Oui. Si le résultat est accepté par le Product Owner et qu'il permet de définir les tâches et qu'il y a de la place pour les mettre dans le sprint courant, pas la peine d'attendre le suivant. Claude
Cette question peut être étendue à toutes les raisons, méconnaissance technique dans le cas du spike, mais manque de précision fonctionnelle également : peut-on commencer un sprint sans avoir chargé toutes les histoires et recommencer un peu plus tard quand les précisions techniques et/ou fonctionnelles ont été approtées sur les user stories identifiées comme prioritaires ?
Si cela arrive systématiquement, c'est que le Product Owner ne prépare pas suffisamment le backlog. Cela n'est pas souhaitable : cela contribue à avoir une réunion de planification trop longue et rendre le sprint difficile à gérer. C'est pour éviter cela que je préconise de faire une revue de backlog quelques jours avant.