What does SPIDR stand for?

SPIDR stands for Spike, Path, Interface, Data, Rules — five different axes you can cut a user story along. Each one is a cut line that produces slices which ship independently, rather than halves that only work together.

How do you use SPIDR to split a user story?

Try each of the five cuts against the story and pick whichever one produces a slice you would actually ship on its own. You don't apply all five — you find the one axis that yields a thin, deliverable slice, and split along it.

Who created the SPIDR technique?

SPIDR was introduced by Mike Cohn as a compact set of five reliable ways to split a user story. It's popular because the five cuts cover most of the situations teams actually hit, and five letters are few enough to run through in your head mid-refinement.

What if none of the SPIDR cuts produce a good slice?

Then you don't have a splitting problem — you have a scope problem. The story is one indivisible piece of work, and the real question is whether you want all of it this sprint or none of it. That's a prioritisation decision, not a splitting one.

Fractionnement des histoires dans SPIDR

SPIDR propose cinq méthodes fiables pour décomposer une user story : Spike, Path, Interface, Data, Rules. Chaque lettre correspond à une ligne de découpage, et chaque découpage produit des tranches pouvant être livrées indépendamment, plutôt que des moitiés qui ne fonctionnent qu’ensemble. C’est la technique de découpage qui résiste le mieux à la plupart des backlogs : lorsqu’une story est trop volumineuse, l’un de ces cinq axes permet presque toujours d’obtenir une tranche que vous pourriez livrer.

Cinq lignes de découpe pour un seul étage. Vous ne les utilisez pas toutes les cinq : vous choisissez celle qui permet d’obtenir une tranche que vous seriez prêt à commercialiser.

Les cinq lignes de découpe

Spike

L’inconnue, c’est justement l’ampleur du projet. Menez une étude dans un délai défini, déterminez la forme du projet, puis estimez son ampleur réelle. C’est l’approche à adopter lorsque l’équipe ne parvient pas à s’accorder sur un chiffre, car personne n’a encore jamais réalisé ce type de projet — consultez la section « Mener un spike » pour savoir à quoi doit ressembler le livrable.

Chemin d’accès

Le scénario comporte plusieurs branches. Commencez par mettre en place le scénario idéal ; les scénarios liés à des données erronées, les états d’erreur et les cas limites feront l’objet de scénarios distincts. L’utilisateur peut atteindre son objectif en suivant le scénario idéal, même si le reste n’est pas encore en place.

Interface

Ce projet comporte plusieurs interfaces : web, mobile, API. Commencez par livrer une interface. Les autres partagent la même implémentation, mais leur livraison s’effectuera selon leurs propres calendriers.

Données

Ce scénario prend en charge plusieurs types et volumes de données. Commencez par présenter le cas le plus simple — un seul locataire, un petit ensemble de données, un format de fichier courant — puis passez aux variantes. Chacune constitue un scénario à part entière, même si le deuxième est, pour l’essentiel, similaire au premier.

Règles

Ce scénario comporte plusieurs règles métier ou rôles. Commencez par mettre en production la règle la plus courante ; les dérogations administratives, les cas particuliers et les exceptions viendront ensuite. Les 80 % des cas peuvent être mis en production sans les 20 % restants.

Lorsque SPIDR ne suffit pas

Si aucune des cinq découpes ne donne lieu à une tranche concrète et livrable, vous n’êtes pas confronté à un problème de découpage, mais à un problème de périmètre. L’histoire constitue un tout indivisible, et la question qui se pose est la suivante : « Voulons-nous tout intégrer dans ce sprint, ou rien du tout ? » Il s’agit d’une question de priorisation, et non de découpage, et aucune technique de découpage, aussi ingénieuse soit-elle, ne pourra en faire une question de découpage.

Choisissez la version qui donne lieu à un extrait que vous seriez prêt à publier. Si aucune ne répond à ce critère, cela signifie que l’article ne doit pas être divisé, mais qu’il faut établir des priorités.

Foire aux questions

Que signifie l’acronyme SPIDR ?

SPIDR est l’acronyme de Spike, Path, Interface, Data, Rules — cinq axes différents selon lesquels vous pouvez segmenter une user story. Chacun d’entre eux constitue une ligne de segmentation qui produit des segments pouvant être livrés indépendamment, plutôt que des moitiés qui ne fonctionnent qu’ensemble.

Comment utilisez-vous SPIDR pour diviser une user story ?

Testez chacune des cinq découpes par rapport au récit et choisissez celle qui permet d’obtenir une partie que vous pourriez réellement livrer telle quelle. Vous n’appliquez pas les cinq découpes : vous identifiez l’axe qui permet d’obtenir une partie concise et livrable, puis vous effectuez la découpe selon cet axe.

Qui a mis au point la technique SPIDR ?

La méthode SPIDR a été présentée par Mike Cohn comme un ensemble concis de cinq méthodes fiables permettant de décomposer une user story. Elle est très appréciée car ces cinq critères couvrent la plupart des situations auxquelles les équipes sont confrontées dans la pratique, et ces cinq lettres sont suffisamment peu nombreuses pour être passées en revue mentalement au cours d’une séance d’affinage.

Et si aucune des découpes SPIDR ne donnait une belle part ?

Dans ce cas, votre problème ne concerne pas le découpage, mais la portée. Le projet constitue un tout indissociable, et la véritable question est de savoir si vous souhaitez en réaliser l’intégralité au cours de ce sprint ou rien du tout. Il s’agit d’une décision de priorisation, et non d’une question de découpage.

Lectures complémentaires

Décomposition des user stories — le diagnostic qui vous indique qu’une décomposition est ce dont vous avez besoin, ainsi que les autres modèles.
Découpe horizontale ou verticale — pourquoi chaque découpe SPIDR doit être verticale.
Comparaison des techniques d’estimation agiles — pour les stories plus floues qui résistent à la division.