Spike en Scrum – définition

spike en scrum
spike en scrum

Dans certains projets informatiques, il n’est pas toujours possible de quantifier une demande ; certains développeurs rejetteraient la demande. Le Spike est là pour compenser ce problème.

Vous pouvez regarder la vidéo de La Minute Agile sur le sujet  :

Types de demandes

Si j’ai une demande qui implique de la recherche, il est évident que mettre des points d’effort sur cette demande n’aurait pas de sens. Si parfois les solutions sont automatiquement proposées par les développeurs, certaines problématiques sont bien plus complexes à résoudre.

Ce type de demande ne sont pas rares sur des projets comme en « Big Data » ou dans les grandes structures où on sait ce qu’on a besoin ; cependant que nous n’avons aucune idée de comment récupérer les données nécessaires… Dans ce cas, mettre des points d’effort sur le ticket n’a pas de sens.

Nous pourrions aussi avoir ce soucis quand on a besoin de faire un choix entre plusieurs solutions mais que cela implique des tests et de la recherche complémentaire.

Un autre cas intéressant d’un besoin de spike peut apparaitre : une user-story est trop grande, il faudra étudier pour la découper voire pour mieux la définir.

Comment se gère un Spike ?

Contrairement à une user-story, on va « timeboxer » le spike afin de bien borner celui-ci. On va définir en début de sprint que celui-ci fera X heures/homme voire X jours/homme.

Dans un projet où on fait des estimations

Cette méthode permettra de garder une bonne cohérence des roadmaps et des planifications ; en Scrum, nous utilisons la somme des points d’effort et la capacité pour planifier. Nous retirons le temps pris des spike du nombre de jour homme utilisé pour calculer la capacité.

Rappel du calcul utilisé pour planifier :

C = V1 / P1 * P2
  • C = la capacité soit la somme des points d’effort autorisées pour le Sprint 4
  • V1 = somme totale de la vélocité des précédents 3 sprint
  • P1 = nombre de jour de dev. des 3 précédents Sprint
  • P2 = nombre de jour de dev. du prochain Sprint

Dans un projet #NoEstimate

Dans un projet où nous n’estimons pas, les impacts des spike ne sont pas très importants. Cependant, il est quand même conseillé de « timeboxer » ses spike car les développeurs pourraient passer un temps indéfinie pour rechercher des choses. Il est souvent utile de cadrer les développeurs sur ce point car ils sont souvent dans l’envie de trouver la solution optimale et/ou de tester de nouvelles choses attractives.

Visuellement ?

Pour représenter les Spike, il est souvent intéressant de les faire sur des post’it d’une autre couleur comme ceci :

user-story et spike
user-story et spike informatique

Pour l’écriture des Spike, j’aime bien garder le même format que les user-story afin de garder une cohérence générale sur les demandes. Par contre, le destinataire ne sera pas forcément un persona car les développeurs ou le Product Owner pourraient être la cible du Spike.

Spike informatique : bien ou pas bien ?

Certains n’aiment pas intégrer des spike mais c’est selon moi une bonne méthode pour avancer sur certains sujets. Il est préférable de faire un spike et de ne pas mettre de points d’effort au maximum sur une demande qui n’est pas estimable dans les faits.

Il est évident que les spike doivent rester limités et ne doivent pas prendre le dessus par rapport aux user-stories. Si c’était le cas, il faudrait peut-être voir pour faire envisager une phase de framing agile.

N’hésitez pas à profiter des spike si votre contexte en a besoin çar cette méthode permet de combler certaines problématiques rencontrées lors de projets Scrum.

[ Article lu 3 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

6 Commentaires

  1. Superbe article, je ne connaissais pas les spikes et sincèrement il nous arrive de mettre une grosse complexité sur une us de type recherche qui au final se fait en moins d’une heure et du coup coup on passe pour des menteurs (voir pire) merci pour l’info 😉

    • Merci Alexis. En effet le Spike permet souvent de répondre à certaines problématiques comme la tienne. Merci pour ton retour sur le sujet car en effet, ça peut aussi éviter des tensions 🙂

  2. Bonjour, je vous remercie pour cet article sincèrement cela m’a aidé surtout que j’avais pas la notion de spike en tête on l’a jamais utilisé mais apparemment on aura recours a cette méthode, sinon est ce que vous avez déjà traité le sujet des points d’effort genre des astuces pour mettre tel valeur comme point d’effort d’une User Story ou Technical Story.

  3. Bonjour,
    Très intéressant cette présentation du spike.
    Nous nous l’utilisons mais je ne sais pas si correctement tout le temps.
    Lorsque nous avons le doute de si une US ou bug est réalisable (techniquement ou autre) nous utilisons le spike. En générale le résultat est une information (sous différents formats) qui sera utilisé plus tard pour réaliser la US réelle.
    Mais souvent elle est aussi utilisé lorsqu’on est pas sûre de pouvoir dans le sprint faire un livrable avec dev + QA à la fin du sprint car il y a de l’inconnu. Et c’est là où je doute de notre façon de faire.
    J’entends que si inconnu il y a le spike aide à éloigner l’inconnu, mais ne devrions nous pas après (sprint suivant) faire la US réelle sur laquelle travailler (faire le dev et la QA)?
    Souvent le résultat du spike est une livraison de dev prête à passer en QA (comme les autres US) et souvent sans acceptance criteria puisque c’est un Spike.
    Qu’en penses-tu?

    Merci de ton opinion

15 Rétroliens / Pings

  1. Calculer la somme des complexités autorisées | Blog Myagile Partner
  2. Faire des user-story de différents storyotypes | Blog Myagile Partner
  3. Comment gérer mes réunions en Scrum ? | Blog Myagile Partner
  4. Sprint 0, doit-on le mettre en place ? | Blog Myagile Partner
  5. Les Nonfunctional Requirements (NFR) en Scrum ? | Blog Myagile Partner
  6. L'agilité dans le monde du Big Data - Blog Myagile Partner
  7. Qu'est-ce que l'Extreme Programming ? - Blog Myagile Partner
  8. Roadmap agile : faire un board - Blog Myagile Partner
  9. What a spike in a scrum project? | Blog Myagile Partner
  10. Sprint 0, doit-on le mettre en place ? - Blog Myagile Partner
  11. Backlog produit, du thème aux user-stories ! - Blog Myagile Partner
  12. Comment mettre des points d'effort dans une équipe ? - Blog Myagile Partner
  13. Les Nonfunctional Requirements (NFR) en Scrum ? - Blog Myagile Partner
  14. Sprint backlog - Scrum.sg
  15. Sprint backlog - My agile Partner Scrum

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.