Bibliothèque · Définition · Intermédiaire
Spike : investiguer avant d'estimer
Une investigation courte et timeboxée pour lever une incertitude technique ou fonctionnelle, quand une story n'est pas estimable en l'état.
Pour qui, pour quand
En résumé
Un spike achète de la connaissance, pas une fonctionnalité. On l'ouvre quand l'équipe ne sait pas comment faire, hésite entre plusieurs solutions, ou ne voit pas comment découper une story trop grosse.
Il est timeboxé (souvent deux jours au plus), il ne compte pas dans la vélocité, et il produit un livrable convenu d'avance : un prototype, une note, une recommandation. On le présente en sprint review.
Méthode étape par étape
dans l'ordre, sans en sauter
- 01Formuler la question précise à laquelle le spike doit répondre.
- 02Fixer la timebox au sprint planning, deux jours au plus.
- 03Convenir du livrable attendu : prototype, note de décision, estimation.
- 04Faire le spike en acceptant du code jetable.
- 05Présenter le résultat en sprint review, puis réécrire ou découper la story.
Questions à me poser
avant de te lancer
- →Quelle question le spike doit-il trancher ?
- →Qu'est-ce qui sera différent pour la story une fois le spike fini ?
- →Est-ce vraiment de l'incertitude, ou une story mal écrite ?
Ce qui coûte cher
les pièges déjà vus sur ce sujet
Dans ma bible
Techniques de priorisation et US · p. 255-256
Chargement du passage…
Sources citées : Jean Claude Grosjean
Mes notes
ce que tu retiens, ton contexte
Situations couvertes
- · L'équipe ne sait pas estimer une user story
- · Une user story est trop grosse ou trop floue pour un sprint
Provenance
Ma bible PM · Techniques de priorisation et US, p. 255-256 · d'après Jean Claude Grosjean
ajoutée le 2026-09-18
Mots-clés
À lire juste après
ce que cette fiche appelle
Ce qui renvoie ici
des fiches qui citent celle-ci - c'est là que tes REX réapparaissent