Suddivisione delle user story che non rientrano in uno sprint

Suddividere una user story significa scindere 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 in gioco.

La maggior parte delle conversazioni del tipo «non siamo in grado di stimarlo» sono, in realtà, conversazioni 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 alla presenza di troppe 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, quindi continua a votare nuovamente per raggiungere un consenso anziché dividersi.
• “Dipende” è la risposta a più di un paio di domande di approfondimento.
• La vicenda si estende oltre i confini di una singola squadra.
• Lo stato “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 (il che è negativo, 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 dei punteggi è il segnale più significativo che ne deriva. Una distribuzione delle carte compresa tra 3 e 13 non è un semplice disaccordo sui numeri. Si tratta di due prospettive 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 concilierà; 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.
• Una persona parte dal presupposto che il progetto esista; un’altra parte dal presupposto di essere lei a progettarlo.
• Una persona si occupa di definire la portata della query; un’altra si occupa di definire la portata dell’implementazione.
• Una persona è a conoscenza dell’esistenza di tale dipendenza; un’altra no.
• Una persona sta effettuando una valutazione 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, non orizzontale: una fetta sottile che sia effettivamente realizzabile di per sé. 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 la sezione «Suddivisione orizzontale vs verticale» per una descrizione completa del principio.

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 ciascuna può essere definita autonomamente.

Il test consiste in un’unica domanda, posta ad ogni fase: l’utente trarrebbe vantaggio da questa funzionalità se la rilasciassimo senza nient’altro? “Imposta preferenze” supera il test: un utente con le preferenze impostate ma senza conferma via e-mail si trova comunque in uno stato utilizzabile. “Invia modulo” non supera il test: un utente la cui richiesta non viene elaborata 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 a cui si sovrappone il vocabolario del flusso di lavoro, 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) viene suddivisa in base alle regole. Si realizzi innanzitutto la regola più comune; seguiranno poi le varianti. Ogni variante costituisce una storia a sé stante, con i propri utenti.

Percorso positivo, poi percorso negativo

Strettamente correlato al concetto di Path di SPIDR. Si realizzi innanzitutto il percorso normale; la gestione degli errori, i tentativi di recupero e i casi limite seguiranno. 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), quindi rilasciate le rifiniture come story a sé stante. Questo funziona se le rifiniture vengono effettivamente rilasciate. I team che trascurano la qualità e non tornano mai sull’argomento finiscono per avere funzionalità incomplete in modo permanente.

Operazioni

Una funzionalità che è in parte una novità per l’utente e in parte una questione operativa (registrazione, monitoraggio, avvisi) si articola proprio lungo questa linea. Si rilascia per prima la parte destinata all’utente; la parte 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; significa 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 implementata, non avete suddiviso la storia. L’avete semplicemente programmata.

Quando una notizia non può essere suddivisa: pubblicatela come notizia in primo piano

A volte l’incognita è proprio la portata stessa del progetto: nessuno lo ha mai fatto prima, 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 attuale delle chiamate, struttura attuale dei dati). È 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), non il codice del prodotto da distribuire. Al termine, si è in grado di stimare con onestà la situazione reale.

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. Definitene la portata come tale, 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 produca qualcosa che l’utente possa utilizzare, anche se gestisce un solo caso. SPIDR fornisce cinque linee di suddivisione affidabili: picco, 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 intenzionalmente prima dell’inizio dello sprint. 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 rispetto a 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 è una divergenza sui valori numerici; 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 storia senza acquisire ulteriori informazioni. Il risultato è una conoscenza (un documento, un prototipo, una misurazione), non il codice di un prodotto pronto per il rilascio. Due elementi lo rendono uno “spike” anziché 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 aspetti operativi, oltre ai cinque criteri SPIDR. Il criterio di valutazione è lo stesso per tutti: l’utente trarrebbe vantaggio dal rilascio di questa singola parte, a scapito di tutto il resto?

Approfondimenti

• “Stima agile: la guida completa” è il punto di riferimento per tutto ciò che riguarda questo argomento.
• La suddivisione della storia di SPIDR analizza in modo approfondito le cinque linee di taglio affidabili.
• La suddivisione orizzontale rispetto a quella verticale è il principio alla base di ogni buona suddivisione.
• Per “pronto” si intende la fase che uno split story deve superare prima di rientrare nello sprint.
• L’affinamento del backlog è la fase in cui avviene effettivamente la suddivisione.