Spike en Scrum ? Aux côtés d’une équipe agile lors de son Sprint Planning ce matin, une petite discussion s’est engagée sur une activité particulière qu’il s’agissait d’embarquer dans le sprint.
Qu’est ce que le Spike pour une équipe agile?
Ou peut être, en premier lieu, ce que ce n’est pas :
le Spike n’est pas 1 User Story (enfin selon moi…).
Je qualifierais davantage le Spike de tâche ou d’activité déclenchée justement pour explorer un sujet, réduire le risque et l’incertude liés à la possible mise en oeuvre d’une User Story.
En bref,
- on ne sait pas trop où on va (notamment techniquement),
- le sujet est très flou,
- la user story n’est pas « PRETE » et ne peut être estimée…
l’équipe a donc besoin d’un petit temps d’étude (technique) pour creuser le sujet. Et bien c’est cela un spike ! Autrement dit une activité d’exploration technique avant tout.
Les caractéristiques d’un Spike – les règles que je recommande
Dans tous les cas, et pour éviter les débordements, j’invite les équipes agiles à calibrer leur spike, cette activité d’étude :
- Le spike est court : au maximum 2 jours ou encore moins de 16 heures
- Le spike est Timeboxé c’est à dire limité dans le temps en fonction de la durée définie pour celui-ci dans le sprint planning (par exemple 8 heures).
- Le spike n’est pas estimé en point d’effort et n’entre donc pas dans le calcul de la vélocité de l’équipe.
- Le spike se termine par la production d’un résultat concret dont la forme a été discutée (Prototype, .doc ou .ppt…)
- Le résultat du spike est examiné lors de la Revue de SPRINT
Et chez vous, le Spike est il une pratique courante? comment l’abordez-vous?
Pour les conseils pratiques d’accompagnement d’équipe agile et de facilitation, appelez-moi ou procurez-vous mon livre « Culture Agile : Manifeste pour une transformation porteuse de sens et cohérente de l’entreprise » . Si vous recherchez un coach à Paris, Genève ou Lausanne pour vous accompagner dans votre transformation? Découvrez mon profil et mes disponibilités.
