Quando singole user stories richiedono un effort di sviluppo che eccede la settimana o, più in generale, quando il team considera le storie troppo grandi per essere lavorate in un colpo solo è necessario riconsiderarle e suddividerle in parti più piccole.
E’ una condizione che capita di continuo ed il Product Owner deve essere allenato ad individuare ragionevoli alternative.
Ma è sempre possibile suddividere una funzionalità?
Sì, non solo è possibile, spesso è addirittura conveniente.
Storie più piccole hanno di solito stime più accurate, sono più gestibili, meno rischiose e offrono al Product Owner il vantaggio di una maggiore flessibilità nella gestione delle priorità.
Vediamo quali possono essere i criteri per dividere le user stories. Ve ne propongo dieci – quelli utilizzati più di frequente – ma è certamente possibile individuarne molti altri adatti alle esigenze di ciascuno (qui ne trovate una mappa mentale).
L’importante è evitare la trappola di suddividere le storie in base ai singoli task necessari per implementarle (i task non sono di alcun valore per l’utente finale!).
Dividere in base al tipo di dati
Questo criterio può risultare particolarmente utile quando si sta implementando una funzionalità di ricerca o nella gestione dei form.
Potremmo infatti individuare dei parametri base di ricerca ed una serie di criteri aggiuntivi o di filtri avanzati che possono essere rilasciati in un secondo momento.
Nella raccolta di dati mediante form possiamo decidere di gestire subito un primo set di informazioni (ad esempio quelle strettamente necessarie al nostro servizio) e abilitare dopo campi accessori e facoltativi. Questa soluzione ha anche il vantaggio di consentire una gestione incrementale delle condizioni di errore.
Dividere in base alle operazioni
In questo caso non ci concentriamo sui dati da gestire ma sul tipo di operazioni che è possibile effettuare sui dati.
L’esempio più classico è il “CRUD” (acronimo di create, read, update, delete), ovvero le operazioni di creazione, lettura, aggiornamento e cancellazione.
Il team di sviluppo può valutare che nel corso di una iterazione sarà in grado di realizzare solo parte del lavoro, ad esempio creare nuovi account per un servizio, associarli ad informazioni di dettaglio e consentirne la consultazione in lettura.
In un’iterazione successiva sarà possibile gestire operazioni di modifica ed eliminazione dei dati.
Dividere in base agli step di processo
Se gestite dei servizi avete inevitabilmente a che fare con processi e workflow.
Un criterio che può rivelarsi utile in questo scenario è segmentare i processi nei singoli step che li compongono.
Prendiamo ad esempio la registrazione di un account. Iniziate a sviluppare il form di raccolta dei dati, poi la visualizzazione in anteprima delle informazioni immesse e infine la pagina di conferma dell’avvenuta registrazione.
E’ ovvio che deciderete di rilasciare al pubblico quando la funzionalità di registrazione sarà del tutto completa, ma mediante un test interno potreste ad esempio scoprire eventuali problemi nella raccolta dei dati ed eliminare delle vulnerabilità prima del roll-out agli utenti finali.
Dividere in base ai flussi di processo
Sempre in tema di processi ed interazioni può tornare utile la decisione di separare “il migliore dei casi possibili” (l’happy path, la versione più semplice) da tutti i flussi in cui qualcosa va storto.
Gestiamo il caso ottimale e poi ci occupiamo di tutte le eccezioni.
Per tornare all’esempio della registrazione implementiamo il caso in cui l’utente non effettua alcun errore in tutto il processo e non ha necessità di modificare i dati inseriti. Creiamo poi ulteriori user stories per gestire i possibili errori e cambi di programma del nostro utente.
Dividere in base al tipo di utente
La stessa funzionalità potrebbe essere utilizzata da tipologie di utenti molto diverse tra loro (ad esempio utente basic, avanzato, utente interno, fornitore, operatore di call center, ecc.).
Ognuno dei nostri interlocutori è guidato da bisogni specifici. Concentriamoci in prima battuta sull’utilizzatore principale ed implementiamo la funzionalità in maniera ottimale per questo soggetto, dopo ci occuperemo degli attori secondari.
Se fate uso di personas vi torneranno molto utili per individuare i bisogni fondamentali che deve soddisfare la funzionalità in oggetto.
Dividere in base alla piattaforma
Nel mondo digitale è sempre più frequente che un servizio sia multi-channel.
Se la medesima funzionalità deve essere portata su tutti i canali si può pensare ad un rilascio incrementale sulla varie piattaforme (separare la parte web, dal sito mobile, da eventuali APP mobile).
E ancora, se abbiamo a che fare con e-commerce e affini, possiamo decidere di implementare diversi metodi di pagamento (carta di credito VISA, AMEX, Mastercard, Pay Pal, ecc.) in più step.
La prima storia sarà la più onerosa in termini di effort, le successive saranno più semplici in quanto variazioni sul tema.
Dividere in base al tipo di requisiti (funzionali e non)
Se l’ambito in cui lavoriamo prevede un’interazione con gli utenti (e quale servizio non prevede oggi un front-end?) dobbiamo per forza curare i requisiti non funzionali.
Ricadono tra questi gli aspetti di performance, scalabilità, usabilità, layout, ecc.
Di solito in questi casi si decide di lavorare prima l’essenza di una funzionalità (il suo aspetto core) e, solo in un secondo momento, i requisiti non funzionali.
Il motto è “make it work, then make it faster”. Prima mettiamo in piedi il motore e verifichiamo che sia effettivamente funzionante, poi lo ottimizziamo con un approccio incrementale e lo vestiamo.
Dividere in base alle priorità
La medesima funzionalità può rispondere ad esigenze di natura diversa (e diversa priorità).
In questo caso tentiamo di suddividere questa funzionalità in user stories più piccole individuando cosa è un must per il rilascio e cosa è un attributo secondario.
Vi ricordate l’approccio 80/20? E’ una tecnica applicabile non solo al backlog ma, il più delle volte, anche a singole user stories.
In generale se vediamo che la medesima storia soddisfa più bisogni di priorità diversa è una buona idea frammentarla ulteriormente.
Dividere in base ai criteri di accettazione
Quando una storia è associata ad un numero consistente di criteri di accettazione è molto probabile che la sua dimensione in termini di effort sia elevata… fosse solo per i test che devono verificarne l’effettivo funzionamento.
In questi casi di solito sollevo la questione con il team: siamo in grado di rispettare tutti i criteri in una volta sola (un unico sprint)? O è più ragionevole pensare di soddisfarne una parte e demandare il resto ad iterazioni successive?
Dividere in base al rischio
Può capitare che il team debba lavorare su ambiti poco conosciuti, con tecnologie nuove o integrando pezzi di terze parti.
In questi casi anche la stima dell’effort può risultare ardua.
Quando non si hanno le idee chiare torna utile suddividere la storia in una prima parte di analisi ed una successiva fase di implementazione. In questo modo prima si acquisiscono le conoscenze necessarie per definire meglio il contesto e le possibili soluzioni con una spike e solo poi si parte a scrivere codice.
E voi? Quali criteri utilizzate più di frequente?
Quali preferite?
Quali altri avete sperimentato?