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.

Suddivisione delle storie in SPIDR

SPIDR consiste in 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 regge al confronto con la 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 — consultate come condurre uno spike per capire quale dovrebbe essere il 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 prevede diverse piattaforme: web, dispositivi mobili, API. Si raccomanda di rilasciare innanzitutto una piattaforma. Le altre condividono la stessa implementazione, ma possono essere consegnate secondo tempistiche autonome.

Dati

La storia affronta diverse tipologie e volumi di dati. Si inizi dal caso più semplice — un unico utente, un set di dati di piccole dimensioni, un 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, bensì di un problema di ambito. La storia è un’opera indivisibile e la questione da affrontare è: «Vogliamo realizzarla tutta in questo sprint, oppure niente?». Si tratta di una questione di priorità, non di suddivisione, e nessuna strategia di suddivisione, per quanto ingegnosa, potrà trasformarla in tale.

Scegliete la versione che produca una parte che potreste effettivamente 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 deve applicare tutti e cinque: deve individuare l’unico asse che produce una porzione snella e pubblicabile, e dividere il testo 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 in rassegna mentalmente durante la fase di perfezionamento.

E se nessuno dei tagli SPIDR producesse una fetta soddisfacente?

Allora non si tratta di un problema di suddivisione, bensì 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.

Letture correlate

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