Dopo aver parlato dei concetti fondamentali delle storie utente, in questa puntata vediamo quali sono le indicazioni da seguire per realizzare buone user stories.
Le storie utente, come fare un buon INVESTimento
Uno degli obiettivi più difficili da perseguire quando si lavora con le user stories, è realizzare delle buone storie, che siano adatte ad essere implementate secondo le pratiche del framework utilizzato (Scrum in questo caso) e che contemporaneamente abilitino un processo di lavorazione basato sui principi agili.
Per aiutare in questo compito è stato coniato uno slogan che dice che le storie devono essere INVEST, dove la sigla sta per Independent, Negotiable, Valuable, Estimatable, Small (della dimensione opportuna) e Testable. Di seguito si analizzeranno uno per uno questi importanti concetti.
Independent
Come si è avuto modo di vedere, sia la composizione del backlog che il suo ordinamento, sono in continua evoluzione: le storie si possono spostare, invertire, inserire o eliminare dalla lista.
Il requisito più importante che le storie devono rispettare affinche’ ciò sia possibile è che siano indipendenti fra loro sia da un punto di logico (flusso di processo) che tecnico (implementativo).
Purtroppo non sempre è possibile ne’ semplice ottenere questa condizione: a volte vi possono essere legami funzionali o anche tecnico-implementativi molto complessi.
Si pensi per esempio a una operazione di validazione di una qualche entità (es. un contratto): per poter essere implementata e provata dall’utente finale, è probabile che prima dovrà essere realizzata la funzione di inserimento, presumibilmente quella di ricerca e infine quella di validazione; il tutto poi dovrà essere inserito in uno specifico flusso di lavoro.
Fra le varie possibili soluzioni per risolvere questo problema, uno è quello di simulare le funzionalità mancanti: per esempio per “simulare” la funzione di creazione, si potrebbe procedere all’inserimento manuale di dati nel database, oppure predisporre una funzione di creazione finta (es. inserisce sempre un contratto prefissato) o dalle ridotte funzionalità (per fare alla svelta la funzione “crea contratto” potrebbe essere realizzata rimandando eventuali controlli sui dati o altre “abbellimenti” non necessari al fine di inserire un contratto nel sistema).
Qualora questo non fosse possibile oppure troppo oneroso, si dovrà invertire l’ordine di implementazione delle funzionalità. Ragionando in termini di valore rilasciato all’utente, implementare la funzione di validazione da sola non aggiunge alcun valore al prodotto finale, quindi si dovrà rivedere l’ordine del backlog.
Negotiable
Le storie dovrebbero essere scritte in modo da catturare l’essenza della funzionalità di business e lasciare spazio per ulteriori discussioni all’interno del gruppo (fra product owner e dev team per esempio), discussioni che saranno focalizzate su dettagli che compongono la storia.
La negoziazione deve essere quel momento in cui ognuno porta il proprio punto di vista nel valutare una storia, in modo da capire se ci sono dei margini per togliere o mettere “cose”. In questo contesto è importante che ogni attore si muova sempre all’interno delle proprie competenze e responsabilità: un caso tipico è quello in cui il product owner tenta di pilotare l’implementazione della storia (è una responsabilità del team), oppure quando il gruppo di sviluppo chiede di apportare modifiche alle funzioni della storia (è una responsabilità del product owner).
Valuable
Uno dei fondanti delle storie utente in Scrum è che ogni storia rilasciata deve sempre aggiungere valore al prodotto: si intende quindi storia di valore, una user story la cui implementazione e il cui rilascio nel sistema finisce per arricchirlo di nuove funzionalità in modo da soddisfare uno o più bisogni di business dell’utente.
Non dovrebbero mai essere ammesse storie per le quali non se ne conosce lo scopo o per le quali non sia chiaro quale sia l’utilità dal punto di vista dell’utente finale. Per questo motivo nel backlog non sono inserite quelle attività che, sebbene necessarie per il proseguimento del progetto (es. installazione di un application server, setup di connessioni per un qualche motore di autenticazione, etc etc), non hanno alcun valore per l’utente finale. Queste sono dette storie tecniche delle quali si parlerà poco più avanti.
Estimatable
Le storie dovrebbero sempre poter essere valutate in modo da capirne il peso ovvero lo sforzo necessario per la realizzazione.
Criteri che possono migliorare il lavoro del team in fase di valutazione sono la dimensione (una storia dovrebbe essere piccola, come specificato nel punto successivo) e un buon set di criteri di accettazione.
Per quanto concerne la dimensione, una storia piccola aiuta il team a capire meglio cosa debba finire dentro la storia; una storia troppo grande invece potrebbe dar luogo a interpretazioni generiche con un margine di variabilità ampio. Analogamente un set di criteri di accettazione aiuta il team di sviluppo a capire meglio come la storia debba essere implementata, ovvero, a parità di funzionalità, il livello di dettaglio delle componenti accessorie: una schermata che presenta un form di login potrebbe avere una grafica minimale oppure estremamente arricchita; potrebbe essere implementata in prima battuta in modo funzionare solo su browser web, rimandando a una iterazione successiva la portabilità sulle altre piattaforme; oppure essere fin da subito realizzata in modo da essere eseguibile sia su tablet che su smartphone. Sono dettagli questi che in genere sono decisi dal product owner in fase di compilazione della storia e che, come facile immaginare, spostano di molto l’impegno richiesto per il suo completamento. Come si avrà modo di vedere più avanti, poter rimandare o anticipare certi dettagli rende possibile un ampio margine di negoziazione e quindi di libertà nel definire il piano di lavoro.
Small
Mantenere le storie piccole aiuta da un lato a tenere sotto controllo il processo di produzione e di evoluzione successiva, ma permette anche di focalizzare meglio lo scope della storia.
Storie grandi invece contengono probabilmente al loro interno troppe informazioni e sono legate a troppi aspetti: in questo caso diventa difficile sia la stima (S di INVEST), l’indipendenza (I di INVEST), così come la negoziazione (N di INVEST).
Quindi piccolo è meglio, per molti motivi: riduce i tempi di sviluppo, aiuta a capire cosa c’è dentro la storia e quindi a stimare, riduce le dipendenze da altre storie e facilità infine il compito di testare (ed eventualmente correggere eventuali errori).
Normalmente il team con l’esperienza impara a valutare la giusta dimensione delle storie; normalmente, dopo qualche tempo, impara ad affettare le storie in modo da avere fette più o meno della stessa dimensione (piccola), tanto da rendere inutile ogni attività di stima col planning poker.
Purtroppo non esiste alcun metro che definisca una soglia sotto la quale la storia è da considerarsi piccola abbastanza. Un buon modo per imparare a tagliare le storie della dimensione giusta, è ripartire da una delle definizioni viste in precedenza: una storia utente esprime un preciso bisogno di business. Quindi il processo di raffinamento di una storia può continuare a smontare e separare storie fino a quando quello che si ottiene continua ad avere un significato di business. Appena ci si rende conto che quello che sia ha in mano non serve a nessuno, significa che si è fatto un passo di troppo.
Si prenda per esempio tre funzioni che si possono trovare all’interno di un ipotetico sistema documentale: la creazione di un contratto, la successiva ricerca e la validazione.
Queste tre operazioni potrebbero essere considerate tre storie diverse, perche’ rispondono a tre esigenze di business differenti: inserimento di una serie di informazioni in un form, la ricerca e la validazione formale. In funzione del preciso contesto di business infatti per l’utente potrebbe essere interessante anche solo inserire il contratto senza effettuare alcune validazione (per esempio si vuole fare un preventivo per il quale non sia necessario avere tutti i campi). Altrettanto interessante potrebbe essere eseguire solo la stampa, magari previa ricerca.
Quindi potrebbe essere corretto dividere la generica storia “Gestione contratti” in tre storie “Inserimento contratto”, “Ricerca contratto” e “Validazione contratto”.
La storia “Inserimento contratto” potrebbe essere ulteriormente scomposta? Si immagini a come potrebbe essere implementata: è presumibile che ci sia un form con i campi di inserimento dati, eventuali etichette di errore, pulsante di salvataggio e altro ancora. In questo caso una scomposizione come potrebbe avvenire? Potrebbe avere senso fare una storia che preveda l’implementazione di mezzo form (solo i primi 20 campi)? oppure solo l’inserimento senza il controllo sintattico dei campi stessi? Probabilmente in entrambi i casi la risposta è no, l’utente non avrebbe alcun interesse a inserire mezzo contratto o inserire i valori senza alcun controllo. Quindi in questo caso una scomposizione della storia in sottoparti non avrebbe molto senso. Ma non è una rgola universale, è una scelta di business. Qualora una parte dei campi di inserimento dovesse essere opzionale, allora si potrebbe immaginare di dividere la storia “inserimento contratto” in una prima parte “Inserimento contratto (campi obbligatori)” e una seconda “Inserimento contratto (campi opzionali)”.
Questo modo di scomporre la storia, non solo potrebbe essere plausibile, ma nella realtà spesso è un ottimo modo che si utilizza per permettere un processo iterativo e incrementale: si rilascia una prima parte della storia con completo significato di business, si effettua il rilascio e si verifica con l’utente se quanto fatto ha senso. In caso positivo si potrebbe procedere alla realizzazione della seconda parte, fiduciosi che quanto fatto ha già ricevuto l’avallo dell’utente.
Altro vantaggio derivante da una scomposizione di questo tipo è una maggior negoziazione fra product owner e dev team in fase di planning: se nello sprint si capisce che non c’è abbastanza posto per una storia completa, si potrà sempre negoziare per accettarne una parte, rimandando l’altra allo sprint successivo.
Testable
La definizione del corpo della storia, i criteri di accettazione, e ogni altro dettaglio devono permettere di realizzare una storia che sia perfettamente funzionante in modo che sia poi tentabile dall’utente o meglio ancora da un sistema automatico. Non dovrà essere lasciate incompleto alcun aspetto della storia, con l’intenzione di tornarci in un secondo momento.
Storie tecniche
Nella costruzione di un prodotto, oltre alla realizzazione delle storie utente, è spesso necessaria l’esecuzione di una serie di attività di preparazione o comunque propedeutiche per il corretto lavoro del team di sviluppo.
Sono operazioni che normalmente non portano valore all’utente finale e che che vanno dalla preparazione di ambienti di lavoro (installare un database o un application server) al deploy di un connettore nell’ambiente di esecuzione.
Trattandosi comunque di lavoro che richiede del tempo per essere svolto, in genere si considerano tali attività come delle storie a tutti gli effetti: i questo caso però, dato che non portano alcun valore di business per l’utente finale, sono chiamate storie tecniche, per distinguerle dalle storie utente.
Proprio perche’ non hanno valore di business, sono gestite direttamente dal team di sviluppo che ha tutte le competenze per compilarle e per valutarne l’effort necessario.
Il product owner infatti non ne comprende appieno l’importanza e sarebbe per esempio di stabilire l’ordine di lavorazione: per questo motivo le storie tecniche non devono essere inserite nel backlog, dato che il confronto con le storie utente le vedrebbe quasi sempre perdenti, e finirebbero per rimanere schiacciate sotto il peso delle altre storie di business.
Normalmente le storie tecniche sono create dal team di sviluppo su propria iniziativa o su indicazione di un qualche stake holder esterno: per esempio il DBA potrebbe “suggerire” di procedere a un qualche lavoro di pulizia degli indici di tabelle particolarmente popolose.
Al momento del planning quindi il dev team, nel caso in cui siano storie tecniche da realizzare, prenderà in consegna nello sprint qualche storia utente in meno, tanto da lasciar un po spazio alle storie tecniche.
Questo fatto è ovvio che rallenta la velocity, essendo questa calcolata sulla somma dei punti delle storie di business completate; non sono prese in considerazione per questa operazione i punti delle storie tecniche. (NOTA: per questioni organizzative, di monitoraggio e di controllo dello stato di avanzamento, anche le storie tecniche sono pesate, tramite una piccola cerimonia a cui no partecipa in genere il product owner).
Questo fatto, il rallentamento della velocity, deve essere gestito con la massima attenzione (scrum master e dev team) in modo da non creare incidenti diplomatici, maldipancia o semplicemente fraintendimenti, con gli altri stakeholder del progetto (product owner in prims).
Condividere ogni dettaglio di quello che accade, rendere trasparente ogni decisione e provare a coinvolgere gli attori esterni sono le tattiche da non dimenticare mai.
Dato che comunque sono spesso viste come degli oggetti estranei, nei limiti del possibile è consigliabile provare a limitare l’insorgere di storie tecniche. Le strategie in questo caso potrebbero essere le seguenti:
Ove possibile provare a trasformarle in storie utente, esplicitando il potenziale valore di business misurabile: in questo modo il product owner avrà più probabilità di fare corrette valutazioni costi/benefici. Una buona strategia potrebbe essere quella di condividere col product owner i motivi e le necessità di tale storia. Per esempio la migrazione verso una nuova versione dell’applicazione server può apparire una operazione poco sensata, ma se si riesce a evidenziare in qualche modo i costi derivanti dalla non migrazione, è probabile che il product owner comprenda l’importanza di tale attività.
Se non è possibile trasformare una storia tecnica in una storia utente, si potrà provare a inglobare l’attività sotto forma di task all’interno di un’altra storia. Per esempio la storia “refactoring dello strato DAO” potrebbe diventare un task della storia “modifica i dati dell’utente”. Ovviamente in fase di stima l’inserimento del “corpo estraneo” aumenta il punteggio finale della storia ospitante. Dato che la storia tecnica potrebbe essere utile per molte storie di business, in questo modo si “carica” il peso della parte tecnica su una sola storia, mentre le altre se la troverebbero già implementata. Per questo motivo abusare troppo di questo stratagemma può dare una visione distorta della realtà, specialmente agli occhi del product owner che potrebbe non comprendere il motivo di tali differenze fra storie all’apparenza molto simili.
Sia che si adotti la tecnica 2 che la 3, per mitigare l’effetto “distorcente” dato dalla presenza di storie tecniche, si consiglia, se possibile, di spalmare le storie “ingrossate” (soluzione 2) o quelle tecniche (soluzione 3) su più sprint. In questo modo la oscillazione della velocity dovrebbe essere sicuramente minore.
Come raccogliere le storie
Il processo di raccolta delle storie e’ una passaggio importante che normalmente si compone di due fasi, una prima raccolta massiva (a inizio progetto) quando si deve comporre la prima versione grezza del backlog e una serie di fasi più piccole in cui si verifica se sono emerse nuove esigenze tali da rendere necessaria la creazione di nuove storie da aggiungere al backlog.
La prima fase di definizione delle storie in genere prende più tempo, tanto che a volte si definisce una vera e propria cerimonia per lo scopo, che può durare nei casi più complessi anche qualche giorno.
Le due tecniche più utilizzate per la raccolta delle storie sono probabilmente lo user story workshop e lo story mapping. Il primo assomiglia a una specie di brain storming in cui ogni membro del gruppo partecipa nella ricerca delle varie funzionalità che si ritiene dovrebbero essere aggiunte al software che si sta sviluppando. È di fatto una riunione poco strutturata organizzata secondo la tecnica che si è vista in precedenza: ogni partecipante propone una serie di funzionalità una per ogni biglietto, poi eventualmente si procede al raggruppamento delle storie simili (eventualmente ogni gruppo può dar vita a una epica o nel caso sia più piccola a una feauture). Questo approccio, dato che parte dalle storie per risalire viene detto bottom up.
Nello story mapping invece si parte elencando tutti i ruoli delle persone che utilizzeranno il sistema (è la parte “in qualità di” della card); per ogni ruolo utente si passa a compilando l’elenco dei bisogni che ogni ruolo/utente in relazione al sistema che si sta componendo. Questi bisogni andranno a comporre una prima lista di epiche.
Dal punto di vista operativo si parte disponendo su una parete (o su un pavimento se vogliamo lavorare in modo più creativo e divertente) dei cartoncini con i nomi o gli avatar dei ruoli utente che si sono individuati.
Qualora lo scenario di partenza sia incerto è si può ricorrere alla tecnica delle personas, che lavora più in profondità sulla natura e sul tipo di comportamento dei vari utenti del sistema. In questo caso si lavora per cercare di rappresentare nel modo più realistico la persona che interagisce col sistema, definendo per esempio aspetti che possono apparire secondari in una analisi classica: si parte creando un personaggio fittizio con nome un avatar e si procede col definire dove usa il sistema (con che tipo di piattaforma?), in quali orari della giornata (orario di ufficio o anche dopocena?), come interagisce col sistema (solo quando si trova in ufficio oppure anche quando la sera da casa desidera controllare lo stato di una pratica?).
Con le personas ci si spinge anche a raccontare il carattere, il tipo di interessi e di preparazione tecnica, in modo da cercare di capire come poi userà il sistema. Questo approccio permette normalmente di evidenziare molte più informazioni e quindi di arrivare a un set di bisogni più preciso. Maggiori approfondimenti circa l’uso delle personas si possono trovare nell’ottimo libro ([IARTA]).
Dopo aver elencato i vari attori o persone che useranno il prodotto, si procede andando a individuare tutte le operazione che ognuna di queste persone vuole eseguire per soddisfare un proprio bisogno: anche in questo caso si pone l’attenzione dal punto di vista dell’utente evidenziando i propri bisogni di business. Questo primo elenco darà vita alle epiche che comporrà poi il backlog.
A questo punto si procede al raffinamento delle epiche provando a individuare le feautures che verranno disposte in orizzontale sotto la epica corrispondente.
A volte risulta utile provare a ordinare le features in modo da rispecchiare la sequenza delle operazioni che l’utente svolge nel flusso che compone la epica. Questo accorgimento può semplificare il lavoro del product owner, in fase di prioritarizzazione del backlog: ovviamente non è una regola dato il product owner potrebbe sconvolgere l’ordine delle storie.
Successivamente si potrà procedere a raffinare ulteriormente le varie features scomponendole in storie. Come si può vedere dalle figure 2 e 3, quello che si ottiene è una mappa bidimensionale, tanto che a volte si parla di Backlog Bidimensionale.
Il livello di raffinamento non è detto che sia uniforme su tutte le colonne (corrispondenti ai vari attori): in alcuni casi si potrà procedere fino a individuare le singole storie, in altre fermarsi alle epiche potrà bastare. La scelta in questo caso sarà guidata dalla priorità data che il product owner stabilisce sia opportuna.
Questa tecnica è stata presentata per la prima volta in forma ufficiale da Jeff Patton nel suo libro riportato in bibliografia ([USM]).
Conclusione
Termina questa seconda puntata dedicata alle storie utente. Restano da vedere alcuni aspetti legati per esempio alla gestione delle storie in fase di Sprint Review a ad alcuni aspetti relativi alle indagini tecniche (spike in gergo Scrum), temi che vedremo il prossimo mese.
Riferimenti
[IARTA] Alan Cooper. “The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity”
http://www.amazon.it/The-Inmates-Are-Running-Asylum/dp/0672326140
[HUSM] “How to create a User Story Map”
http://winnipegagilist.blogspot.it/2012/03/how-to-create-user-story-map.html
[AR-USM] Andrea Gigante, “Creating an Agile Road Map Using Story Mapping”
[USM] Jeff Patton, “User Story Mapping”
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.