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 prioritization decision, not a splitting one.

Suddivisione delle storie in SPIDR

SPIDR consiste in cinque metodi affidabili per suddividere una user story: spike, percorso, interfaccia, dati, regole. Ogni linea di suddivisione: quando funziona e quando produce una suddivisione errata.

SPIDR rappresenta cinque metodi affidabili per suddividere una user story: Spike, Path, Interface, Data, Rules. Ogni lettera rappresenta una linea di divisione e ogni divisione produce parti che possono essere rilasciate in modo indipendente, anziché metà che funzionano solo insieme. Si tratta della tecnica di suddivisione che meglio si adatta alla maggior parte dei backlog: quando una storia è troppo ampia, uno di questi cinque assi produce quasi sempre una parte che potreste rilasciare.

Cinque linee di taglio che attraversano una storia. Non le si utilizzano tutte e cinque. Si individua quella che produce una sezione che si è effettivamente disposti a pubblicare.

Le cinque linee di taglio

Spike

L’incognita è proprio la dimensione. Conducete un’indagine con un limite di tempo prestabilito, individuate la struttura, quindi stimatene la portata effettiva. Questa è la soluzione da adottare quando il team non riesce a concordare una cifra perché nessuno ha mai affrontato una situazione simile in precedenza. Valutate la possibilità di eseguire uno “spike” per capire quale dovrebbe essere l’aspetto del risultato finale.

Percorso

La storia presenta diversi percorsi. Si realizzi innanzitutto il percorso ottimale; i percorsi relativi a dati errati, gli stati di errore e i casi limite costituiscono storie a sé stanti. L’utente può raggiungere l’obiettivo seguendo il percorso ottimale anche se il resto è ancora incompleto.

Interfaccia

Il progetto presenta diverse piattaforme: web, mobile, API. Si realizzi innanzitutto una piattaforma. Le altre condividono la stessa implementazione, ma possono essere consegnate secondo tempistiche autonome.

Dati

La storia gestisce diverse tipologie o volumi di dati. Si inizi dal caso più semplice (singolo tenant, set di dati di piccole dimensioni, formato di file comune), per poi passare alle varianti. Ciascuna di esse costituisce una storia a sé stante, anche quando la seconda è sostanzialmente simile alla prima.

Regole

La funzionalità presenta diverse regole aziendali o ruoli. Si dovrebbe implementare innanzitutto la regola più comune; seguiranno poi le deroghe amministrative, i casi particolari e le eccezioni. L’80% dei casi può essere implementato senza il restante 20%.

Quando SPIDR non è d’aiuto

Se nessuno dei cinque tagli produce una porzione concreta e pronta per la consegna, non si tratta di un problema di suddivisione. Ha un problema di ambito. Il progetto è un’opera indivisibile e la questione è: «Vogliamo realizzarlo tutto in questo sprint o non realizzarne alcuna parte?». Si tratta di una questione di priorità, non di suddivisione, e nessuna suddivisione, per quanto ingegnosa, potrà trasformarla in tale.

Scegliete la versione che produca un articolo che sareste effettivamente disposti a pubblicare. Se nessuna di esse soddisfa questo requisito, la storia non richiede di essere suddivisa, ma di essere ordinata per priorità.

Domande frequenti

Cosa significa l’acronimo SPIDR?

SPIDR è l’acronimo di Spike, Path, Interface, Data, Rules: cinque diversi assi lungo i quali è possibile suddividere una user story. Ciascuno di essi rappresenta una linea di suddivisione che produce parti rilasciabili in modo indipendente, anziché metà che funzionano solo insieme.

Come si utilizza SPIDR per suddividere una user story?

Provi ciascuno dei cinque tagli in relazione alla storia e scelga quello che produce una porzione che sarebbe effettivamente disposto a pubblicare separatamente. Non li applichi tutti e cinque. Trovi l’unico asse che produce una porzione snella e pubblicabile, e effettui la suddivisione lungo tale asse.

Chi ha ideato la tecnica SPIDR?

Lo SPIDR è stato introdotto da Mike Cohn come un insieme sintetico di cinque metodi affidabili per suddividere una user story. È molto diffuso perché questi cinque criteri coprono la maggior parte delle situazioni che i team si trovano effettivamente ad affrontare, e cinque lettere sono sufficientemente poche da poter essere passate mentalmente in rassegna durante la fase di perfezionamento.

E se nessuno dei tagli SPIDR producesse una fetta soddisfacente?

Allora non si tratta di un problema di suddivisione. Si tratta di un problema di ambito. Il progetto è un’opera indivisibile, e la vera domanda è se si desidera realizzarlo interamente in questo sprint oppure non realizzarne alcuna parte. Si tratta di una decisione relativa alle priorità, non di una questione di suddivisione.

Approfondimenti

Suddivisione delle user story: la diagnosi che indica quando è opportuno procedere a una suddivisione, oltre agli altri modelli.
Taglio orizzontale contro taglio verticale: perché ogni taglio SPIDR deve essere verticale.
Confronto tra tecniche di stima agile: per storie più vaghe che resistono alla suddivisione.