Pourquoi utiliser des Spikes dans un projet agile Scrum ???

Lors de la séance de Sprint Planning, ou la cérémonie de l’affinage, l’équipe de développement peut se confronter à plusieurs situations à l’occurrence :

• Plusieurs solutions proposes pour une User Story, et on ne sait pas laquelle est optimale. 

• Pas de solution technique à proposer par l’équipe de développement pour une demande ou User Story. 

• Une user Story ou Epic de grande taille, on ne peut pas la finaliser dans un seul Sprint, alors il faut l’étudier pour le bien décomposer et définir son contexte.

Dans ces cas de figure cites ci-dessus, on ne peut pas embarquer ces demandes dans le Sprint en cours, du coup on aura besoin d’utiliser des Spikes pour décider. 

Un Spike est tout simplement une demande d’analyse et recherche Permettant de soit faire le choix entre plusieurs solutions, soit explorer un outil ou une demande, ou bien trouver la bonne manière pour découper un Epic ou une User Story de grande taille qu’on ne peut pas l’achever dans un seul Sprint. 

Durant le Rituel du Sprint Planning on peut embarquer une ou plusieurs Spikes, leurs résultats ne sera exploités qu’à partir du prochain Sprint.

En cas général, un Spike doit être limité dans le temps (Timeboxé) et ne doit pas consommer trop de charge, normalement il est limité à une journée ou parfois 2 jours dans les cas complexes de recherche et investigation.

La règle d’utilisation des Spikes est claire :

• Embarquer le Spike dans le Sprint N.

• Embarquer la demande concernée par le résultat du Spike dans le Sprint N+1. 

 Un exemple clair et concret pour l’utilisation de Spike est le domaine BIG DATA, parfois on sait bien quoi faire par les données impactées, mais on n’a aucune idée sur comment les récupérer à partir du Datawherehouse ou l’entrepôt de données.

 Conclusion :

L’utilisation des Spikes reste pour moi l’une des meilleures solutions pour faire avancer les demandes bloquées ou qui nécessitent des décisions et arbitrage. 

N’hésiter pas à utiliser les Spikes dans vos Sprints, mais d’une manière logique afin de ne pas impacter la vélocité de l’équipe, et en étroite collaboration avec le Product Owner.