Suddivisione delle user story che non rientrano in uno sprint

Una storia di cui non si riesce a valutare la portata è solitamente una storia che non è ancora pronta per essere pubblicata. Come capire quando è il momento di suddividerla, quali sono le linee di divisione che producono parti pubblicabili e quali invece danno solo l’impressione di farlo.

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 consente di riportarla sul tabellone.

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 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, 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.
  • “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.

One oversized story splitting into three thinner slices ? ? too big won't fit in a sprint ✓ slice 1 shippable ✓ slice 2 shippable ✓ slice 3 shippable each slice ships on its own
La storia che non riesce a trovare una forma completa si trasforma in tre parti che procedono ciascuna per conto proprio, non in due metà di nulla.

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

Quando i membri di un team di diverse dimensioni collaborano utilizzando il planning poker, un’ampia dispersione delle valutazioni rappresenta il segnale più significativo che ne deriva. Una distribuzione delle carte che va dal 3 al 13 non è un semplice disaccordo sui numeri. Si tratta piuttosto 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 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.
  • Una persona parte dal presupposto che il progetto esista; un’altra parte dal presupposto di essere colei che lo sta progettando.
  • 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 esigenze di qualcuno presente nella sala; il lavoro è di competenza di 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 porzione snella che sia effettivamente consegnabile di per sé. L’approccio “prima il backend, poi il frontend nello sprint successivo” suddivide la story 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 da prendere in considerazione. Esistono alcuni altri modelli che ricorrono con sufficiente frequenza da meritare di essere menzionati.

Fasi del flusso di lavoro

Una storia che abbraccia l’intero percorso dell’utente (registrazione, impostazione delle preferenze, conferma dell’indirizzo e-mail, visualizzazione della dashboard) spesso si articola in modo netto in base ai confini tra le singole fasi. Quando funziona, rappresenta la tecnica più chiara a disposizione: ogni storia produce un risultato riconoscibile e visibile all’utente, ciascuna può essere presentata in una demo e ogni singola storia può essere definita 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? “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 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) viene suddivisa in base alle regole. Si dovrebbe implementare per prima 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 all’approccio Path di SPIDR. Si implementa innanzitutto il percorso normale; la gestione degli errori, i tentativi di recupero e i casi limite vengono affrontati in seguito. 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 vi fanno mai ritorno si ritrovano con funzionalità incomplete in modo permanente.

Operazioni

Una funzionalità che è in parte orientata all’utente e in parte di natura 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 rappresenta un rischio, non una porzione. Se una parte del lavoro acquista 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 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), 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; si tratta di 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 è in realtà 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 un unico progetto, 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: picco, percorso, interfaccia, dati, regole. Scegliete quella che produce una sezione che potreste effettivamente rilasciare.

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 versione 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 la risposta “dipende” viene data a più di un paio di domande di approfondimento, oppure quando la story coinvolge più di un team. Un ampio divario non è una divergenza 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 acquisita (un documento, un prototipo, una misurazione), non il codice di un prodotto pronto per il rilascio. 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?

Approfondimenti