Suddivisione delle user story che non rientrano in uno sprint

Suddividere una user story significa scomporre una storia troppo ampia in storie più piccole, ciascuna delle quali offra comunque qualcosa di utilizzabile per l’utente. Una storia che non è possibile stimare è solitamente una storia che non è ancora possibile rilasciare — e la suddivisione è la mossa che la riporta sul tabellone.

La maggior parte delle conversazioni del tipo «non siamo in grado di stimarlo» sono, in realtà, discussioni sulla suddivisione del lavoro sotto mentite spoglie. Il team non ha un problema legato ai numeri e allo sforzo richiesto; ha piuttosto un problema legato al numero eccessivo di incognite. La suddivisione riduce le incognite fino a quando la storia non assume la forma di un lavoro già svolto in precedenza — e le stime convergono.

Quando smettere di fare stime e iniziare a suddividere

Una storia che non rientra in uno sprint non è un problema di dimensioni, ma di forma. Prestate attenzione ai segnali:

• Il team esprime voti pari a 13 e 20, poi continua a votare nuovamente per raggiungere un consenso anziché dividersi.
• “Dipende” è la risposta a più di un paio di domande di approfondimento.
• La vicenda coinvolge più di una squadra.
• “Completato” richiede più operazioni di distribuzione.
• È possibile descriverlo in due frasi, ma non in due criteri di accettazione.

Se si decide comunque di andare avanti, il team trascorre lo sprint cercando di portare a termine il lavoro e rimanda a dopo ciò che resta — con scarsi risultati, poiché ciò che viene rimandato è proprio la parte più difficile — oppure completa un sottoinsieme pronto per la consegna e lo considera concluso, mentre il resto rimane a metà. Entrambe le soluzioni sono peggiori rispetto alla scelta di suddividere il lavoro in modo mirato prima dell’inizio dello sprint.

Perché un ampio divario nei voti implica una divisione, e non una nuova votazione

Quando i membri di un team collaborano utilizzando il planning poker, un’ampia dispersione delle valutazioni rappresenta il segnale più significativo che ne deriva. Una distribuzione delle carte compresa tra 3 e 13 non è un semplice disaccordo sui numeri. Si tratta piuttosto di due storie diverse che fingono di essere una sola. Chi assegna un 3 vede un ambito; chi assegna un 13 ne vede uno diverso. Una nuova votazione non li metterà d’accordo: il vero lavoro consiste nel discutere quale dei due ambiti sia quello reale. Ecco cosa accade solitamente dietro le quinte:

• Una persona sta valutando lo scenario ottimale; un’altra sta valutando i casi limite.
• C’è chi dà per scontato che il progetto esista; c’è chi dà per scontato di essere lui a progettarlo.
• Una persona si sta occupando della valutazione della query; un’altra si sta occupando della valutazione dell’implementazione.
• Una persona è a conoscenza dell’esistenza di tale dipendenza; un’altra no.
• Una persona sta valutando le dimensioni per conto di qualcuno presente nella sala; il lavoro spetta a un altro team.

Aggiungere ulteriori dettagli raramente risolve il problema: si ottiene un ticket più lungo, non una stima più precisa. La suddivisione, invece, sì: in un picco se l’incognita riguarda la causa, in sezioni verticali se l’incognita riguarda l’ambito. Il fatto che le due schede siano separate non significa che il team sia in disaccordo. Significa che il team sta votando su storie diverse. La rimandi indietro.

Tagliate in senso verticale, non orizzontale

La suddivisione deve essere verticale — una sezione snella che sia effettivamente consegnabile di per sé — e non orizzontale. L’approccio “prima il backend, poi il frontend nello sprint successivo” suddivide la storia come un coltello taglia la pasta: si ottengono due metà che non contengono nulla. Una fetta verticale tocca ogni livello e consente di consegnare una colonna funzionante — un pulsante che funziona dall’inizio alla fine, anche se gestisce un solo caso di input. Si veda suddivisione orizzontale vs verticale per il principio completo.

Modelli di suddivisione efficaci

SPIDR — spike, path, interface, data, rules — copre la maggior parte delle situazioni di suddivisione ed è il primo punto di riferimento da consultare. Esistono alcuni altri modelli che ricorrono con sufficiente frequenza da meritare di essere menzionati.

Fasi del flusso di lavoro

Una story che copre l’intero percorso dell’utente — registrazione, impostazione delle preferenze, conferma dell’indirizzo e-mail, visualizzazione della dashboard — spesso si articola in modo netto lungo i confini tra le singole fasi. Quando funziona, rappresenta la tecnica più chiara a disposizione: ogni story produce un risultato riconoscibile e visibile all’utente, ciascuna può essere presentata in una demo e il suo ambito può essere definito autonomamente.

Il test consiste in un’unica domanda, posta ad ogni fase: l’utente ne trarrebbe vantaggio se rilasciassimo solo questa funzionalità e nient’altro? La funzione “Imposta preferenze” supera il test: un utente che ha impostato le preferenze ma non ha ricevuto la conferma via e-mail si trova comunque in uno stato utilizzabile. “Invia modulo” non supera il test: un utente il cui invio non porta a nulla si trova in una situazione peggiore rispetto a prima. Se la risposta è no, il passaggio è un’attività secondaria, non una storia, e il flusso di lavoro non si divide in quel punto.

La versione più rapida dello stesso test: ogni fase potrebbe entrare in produzione nell’arco di tre sprint senza che nulla altro cambi, garantendo un’esperienza coerente in ogni fase? Se saltare una fase porta l’utente a visualizzare una pagina non funzionante, la suddivisione è fasulla. Questa è la trappola in cui cadono i team di ingegneri: le fasi corrispondono alla suddivisione del codice (servizio di autenticazione, API delle preferenze, componente della dashboard), quindi sembrano granulari. Sono effettivamente granulari. Sono anche sezioni orizzontali con un vocabolario relativo al flusso di lavoro sovrapposto, e nessuna di esse fornisce nulla all’utente. L’indizio rivelatore: ogni «fase» è di competenza di un solo specialista. Le vere fasi del flusso di lavoro attraversano lo stack, proprio come fanno le vere fasi rivolte all’utente.

Variazioni delle regole aziendali

Una storia che prevede più regole o ruoli — utente normale, amministratore, client API — va suddivisa per regola. Si inizi con la regola più comune; le varianti seguiranno. Ogni variante costituisce una vera e propria storia con i propri utenti.

Percorso positivo, poi percorso negativo

Strettamente correlato all’approccio Path di SPIDR. Si fornisce innanzitutto il percorso ottimale; la gestione degli errori, i tentativi di recupero e i casi limite vengono dopo. L’utente può ottenere un esito positivo anche prima che le modalità di errore siano state completamente gestite — a condizione che, nel frattempo, si accetti un comportamento di errore meno ottimale e che si provveda effettivamente a risolvere il problema in un secondo momento.

Qualità differita

Rilasciate la versione senza rifiniture — senza tooltip, senza animazioni, senza modifiche amministrative — e poi rilasciate le rifiniture come una storia a sé stante. Questo funziona se le rifiniture vengono effettivamente rilasciate. I team che trascurano la qualità e non vi fanno mai ritorno finiscono per ritrovarsi con funzionalità incomplete in modo permanente.

Operazioni

Una funzionalità che è in parte una novità per l’utente e in parte una questione operativa (registrazione dei dati, monitoraggio, avvisi) si articola proprio lungo questa linea. Si rilascia per prima la parte destinata all’utente; quella operativa viene implementata in un secondo momento e spesso richiede meno tempo, poiché la funzionalità è già in produzione e le lacune sono evidenti.

Cosa non costituisce una vera e propria scissione

“Frontend in questo sprint, backend nel prossimo” non significa suddividere il lavoro, ma rinviare la consegna, poiché nessuna delle due parti viene rilasciata da sola. “Realizzarlo e poi scrivere i test” segue lo stesso principio: il codice non testato è un rischio, non una parte. Se un’attività ha valore solo una volta che la parte correlata viene consegnata, non avete suddiviso la storia. L’avete semplicemente programmata.

Quando una notizia non può essere suddivisa: pubblicatela integralmente

A volte l’incognita è proprio la portata stessa: nessuno ha mai fatto una cosa del genere prima d’ora, l’API del fornitore non fornisce una risposta alla domanda fondamentale sulla capacità di carico, oppure il lavoro dipende da una misurazione di cui nessuno dispone ancora (p99 attuale, volume di chiamate attuale, struttura dei dati attuale). È in questi casi che si avvia uno «spike»: un’indagine a durata prestabilita il cui risultato è la conoscenza — un documento, un prototipo, una raccomandazione, una misurazione — e non il codice di un prodotto da rilasciare. Al termine, si è in grado di valutare la situazione reale in modo onesto.

Gli spike vengono spesso utilizzati in modo improprio con l’atteggiamento del tipo «cominciamo e vediamo cosa succede». Quello non è uno spike: è una story non stimata con passaggi aggiuntivi. Due segnali che indicano che state utilizzando lo strumento sbagliato: non viene data risposta a una domanda specifica, oppure il risultato atteso è «la funzionalità è stata realizzata». Il primo significa che il team non è effettivamente incerto; il secondo significa che si tratta di una storia.

Se una singola fase non è ancora sufficiente, il progetto non è ancora pronto: si tratta di un progetto vero e proprio. Definitene la portata complessiva, comunicate la tempistica e smettete di fingere che uno sprint possa bastare.

Domande frequenti

Come si suddivide una user story?

Suddividetelo verticalmente — in base ai risultati per l’utente, in modo che ogni sezione tocchi ogni livello e fornisca qualcosa che l’utente possa utilizzare, anche se gestisce un solo caso. SPIDR offre cinque linee di suddivisione affidabili: spike, percorso, interfaccia, dati, regole. Scegliete quella che produce una sezione che rilascereste effettivamente.

Cosa fate quando una user story è troppo ampia per uno sprint?

Suddividetela prima dell’inizio dello sprint, di proposito. Una story che non rientra nei tempi viene riportata alla sessione successiva in modo inadeguato — ciò che rimane è proprio la parte più complessa — oppure rilasciata come sottoinsieme incompleto. Entrambe le soluzioni sono peggiori di una suddivisione verticale deliberata in parti, ciascuna delle quali viene rilasciata separatamente.

Quando è opportuno suddividere una storia anziché stimarne la durata?

Quando il team non riesce a inserirlo in uno sprint, quando i voti presentano un ampio divario (un 3 accanto a un 13), quando a più di un paio di domande di approfondimento si risponde con un «dipende», oppure quando la story coinvolge più di un team. Un ampio divario non è un disaccordo sui numeri: si tratta di due storie che fingono di essere una sola.

Che cos’è uno “spike” nell’agile?

Uno “spike” è un’indagine a durata prestabilita, avviata quando il team non è in grado di valutare la portata di una story senza acquisire ulteriori informazioni. Il risultato è una conoscenza — un documento, un prototipo, una misurazione — e non il codice di un prodotto da rilasciare. Due elementi lo rendono uno “spike” piuttosto che un lavoro a tempo indeterminato: un limite di tempo e un risultato da consegnare.

Quali sono i modi più comuni per suddividere una user story?

Fasi del flusso di lavoro, variazioni delle regole aziendali, percorso previsto e percorso non previsto, qualità differita e problematiche operative — oltre ai cinque criteri SPIDR. Il criterio di valutazione è lo stesso per tutti questi aspetti: l’utente trarrebbe vantaggio dal rilascio di questa singola parte, a scapito di tutto il resto?

Letture correlate

• Stima agile: la guida completa — il punto di riferimento per tutto ciò che riguarda questo argomento.
• Suddivisione della trama di SPIDR — le cinque linee di taglio affidabili, analizzate in dettaglio.
• Suddivisione orizzontale vs verticale — il principio alla base di ogni buona suddivisione.
• Definizione di “ready” — la fase che una versione parziale deve superare prima di rientrare nello sprint.
• Affinamento del backlog — la fase in cui avviene effettivamente la suddivisione.