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 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 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 narrative che attraversano una storia. Non le si utilizzano tutte e cinque. Si individua quella che produce una parte che si è effettivamente disposti a pubblicare.

Le cinque linee di taglio

Spike

L’incognita è 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 diventano 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 saranno consegnate secondo tempistiche autonome.

Dati

La storia gestisce diverse tipologie e 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. Si tratta di un problema di ambito. Il progetto è un’opera indivisibile e la questione da affrontare è: «Vogliamo realizzarlo interamente in questo sprint, oppure non realizzarne alcuna parte?». Si tratta di una questione di priorità, non di suddivisione, e nessuna strategia di suddivisione, per quanto ingegnosa, potrà trasformarla in tale.

Scegliete il taglio che produce una parte che potreste effettivamente pubblicare. Se nessuno di essi 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 parte che sarebbe effettivamente disposto a pubblicare da sola. Non li applichi tutti e cinque. Trovi l’unico asse che produce una parte snella e pubblicabile, e la suddivida 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 sufficienti per poterle passare in rassegna mentalmente durante la fase di perfezionamento.

E se nessuno dei tagli SPIDR producesse una fetta soddisfacente?

Allora il problema non riguarda la suddivisione. Il problema riguarda l’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 suddivisione.

Approfondimenti

Suddivisione delle user story: la valutazione che Le indica se una suddivisione è ciò di cui ha bisogno, oltre agli altri modelli.
Suddivisione orizzontale vs verticale: perché ogni taglio SPIDR deve essere verticale.
Confronto tra tecniche di stima agile: per storie più vaghe che resistono alla suddivisione.