Cos’è una User Story? Come (e perché) scriverla
Le User Stories sono uno strumento centrale nella collaborazione dei team agili. Il loro campo di applicazione è ampissimo e va dalla soddisfazione di specifiche esigenze dei clienti, al supporto dei team Scrum.
Ma cos’è esattamente una User Story e come si fa a realizzarla? In questo articolo faremo chiarezza su questo concetto: vi mostreremo come va strutturata una storia utente e come lavorare con successo con questo strumento.
Alla scoperta delle User Stories
User Story: definizione
User Story è una dicitura inglese che, letteralmente, è traducibile con “storia utente”. Nell’ambito della gestione agile dei progetti e dello sviluppo di software, la User Story è uno strumento che consente di descrivere le funzionalità di un dato sistema dal punto di vista dell’esperienza dell’utente.
A cosa serve?
La funzione della User Story è quella di soddisfare specifiche esigenze dell’utente e le sue aspettative riguardo ad alcune funzionalità di un software o di una soluzione proposta.
La storia utente, infatti, ha lo scopo di far comprendere al lettore quale sia il beneficio del sistema preso in esame. In questo modo è possibile raggiungere un più alto grado di sensibilizzazione rispetto ai vantaggi apportati dal prodotto o servizio presentato.
Una User Story, in fin dei conti, serve, dunque, a far aumentare la comprensione di un sistema e, quindi, ad incentivare il suo grado di successo tra gli utenti.
User Story vs. Use Case
Lo Use Case, o caso d’uso, può essere considerato come una versione più massiccia della User Story. Infatti, esso è molto elaborato e dettagliato, copre un contesto più ampio ed è, quindi, più completo di una storia utente. Solitamente esso comprende addirittura più User Stories.
Il caso d’uso è normalmente più durevole di una storia utente. Esso, infatti, viene di solito mantenuto per tutto lo sviluppo del sistema, mentre la User Story scompare al suo completamento in uno Sprint.
Scrivere una User Story
Chi la scrive?
Le storie utente possono essere scritte da o per gli utenti.
Come si scrive?
Normalmente la User Story è frutto di un team di lavoro, che si dedica alla sua redazione e ottimizzazione. Normalmente il gruppo si concentra, innanzitutto, sullo sviluppo di determinati criteri attorno ai quali sviluppare la propria storia. Questi possono essere, ad esempio, il grado di complessità, il modello da seguire, l’impostazione delle informazioni, e così via.
Da principio, dunque, vanno definite le proprietà strutturali che si vogliono attribuire alla storia. Se si opera in team, è bene suddividere i compiti all’interno del gruppo e fissare l’arco temporale in cui il lavoro deve essere svolto.
Per cominciare, vanno, quindi, stabiliti degli Story Points, ovvero numeri arbitrari utilizzati per stimare quanto lavoro il team è in grado di portare a termine in ogni iterazione.
Quindi, vanno fissati eventualmente anche degli Sprint, ovvero dei cicli di lavoro di durata da una a quattro settimane. L’insieme degli Story Points e degli Sprint costituiscono la base del Planning della User Story.
☝ In questo contesto si è parlato di Sprint al plurale. Tuttavia, si noti che, per la realizzazione di una User Story, è spesso necessaria una sola iterazione o Sprint.
Lo step successivo è quello di assicurarsi che le task siano espresse in modo chiaro e siano assegnate a diversi membri del gruppo di lavoro. L’organizzazione e la coordinazione sono, infatti, fondamentali per poter redigere una User Story di qualità.
Tuttavia, capita che le User Stories vengano redatte senza che ci sia stata un’analisi dettagliata delle attività da svolgere. Il grado di strutturazione della storia è, infatti, un fattore arbitrario e soggetto alla libera scelta del gruppo di lavoro. Chiaramente, più un team mira a garantire servizi di eccellenza, più prediligerà una pianificazione articolata della User Story.
☝ Il planning della User Story deve avere come fine il beneficio dell’utente, non la promozione della soluzione, prodotto o servizio in esame.
Come si procede?
Le storie utente vengono gestite nel Backlog. In questo contesto entra in gioco il concetto DEEP, sviluppato da Roman Pichler. Egli ha ideato questo modello al fine di operare un Backlog corretto. DEEP è un acronimo, che sta a designare le seguenti parole:
- Detailed Appropriately (dettagliate in modo adeguato): le storie utente ad alta priorità vanno formulate in modo più dettagliato rispetto a quelle a bassa priorità.
- Estimated (valutate): le componenti della User Story vanno valutate, soprattutto in relazione agli Story Points. Conoscere, anche se solo in modo approssimativo, gli elementi costituenti una storia aiuta a stabilire le priorità e a tracciare il progetto di rilascio.
- Emergent (emergenti): la User Story ha un carattere dinamico. Infatti, essa si evolve e il suo contenuto può cambiare frequentemente. Nuovi elementi possono emergere sulla base delle valutazioni e dei feedback dei lettori. Su questa base, le storie utente vanno modificate, aggiornate e ottimizzate.
- Prioritized (priorizzate): le componenti delle storie o le storie stesse ad alta priorità vanno implementate per prime.
Che impostazione dare ad una User Story?
Quando si è in procinto di scrivere una storia utente, è bene tenere a mente una struttura raccomandata di base:
Come x (ruolo di chi scrive), vorrei xy (riferimento alla funzionalità desiderata), al fine di yy (scopo).
Oltre a questo modello di base esistono altre alternative. Un altro modello possibile per una storia utente è, ad esempio:
Per poter yy (scopo), dal momento che sono x (ruolo), vorrei xy (funzionalità).
☝ Il ruolo deve essere fatto coincidere le vostre Personas. Una Persona è un tipico rappresentante del vostro gruppo target.
Le storie utente, come d’altra parte tutte le storie, possono variare nel grado di dettagli fornito. Infatti, alcune storie possono limitarsi a fornire un contenuto molto approssimativo. Altre, invece, possono presentare un esordio generico, per poi perfezionarsi solo successivamente. Altre ancora possono mostrarsi dettagliate fin dal principio.
Attenersi ad un modello per formulare la propria User Story non è obbligatorio, ma risulta pratico. L’esperienza nel settore delle storie utente ha mostrato che il mantenimento della struttura di base raccomandata non solo favorisce la formulazione, ma facilita anche la comprensione da parte del lettore.
In che lingua va scritta?
La lingua da preferire per scrivere una User Story è l’inglese. Potrebbe risultare una scelta strana, soprattutto se si è attivi nel panorama italiano. Tuttavia, ormai da tempo l’inglese è diventato la lingua franca in quasi tutti i paesi ed è una lingua ormai parlata a livello internazionale.
Per di più, questa lingua consente un alto grado di concisione, dal momento che si presenta estremamente sintetica e diretta.
Per questo può risultare una scelta assennata proporre la propria User Story in inglese.
Esempi di User Story
Di seguito alcuni esempi di applicazione dei modelli di storia utente proposti.
1. Come amante dei romanzi storici, vorrei essere informato sui relativi libri in uscita, al fine di poter ordinarli per tempo in libreria.
2. Come amante dei film di avventura, vorrei sapere che pellicole di questo genere sono uscite nel vostro cinema, al fine da poter acquistare i biglietti online.
3. Per poter trovare un abbonamento conveniente, dal momento che sono un amante del cinema, vorrei ricevere informazioni sulle promozioni disponibili nel vostro cinema.
Consigli per una User Story di qualità
Dal momento che la User Story mira ad essere recepita e compresa nel minor tempo possibile, è importante che essa:
- Sia redatta utilizzando frasi brevi e incisive;
- Riporti un vocabolario semplice e poco ricercato;
- Eviti tecnicismi: persone senza alcun background specialistico devono essere in grado di capire quello che stanno leggendo;
- Si focalizzi nel fornire risposte dirette alle domande: chi vuole cosa dal sistema? Perché l’utente usufruisce del sistema (per trarre quale beneficio)?
Secondo le parole di Mike Cohn, uno dei principali contributori all'invenzione della metodologia di sviluppo software Scrum, tutte le storie utente agili includono solo una o due frasi scritte in modo semplice e, cosa più importante, una serie di conversazioni attivate di conseguenza sulla funzionalità desiderata.
Strumenti di gestione: criteri di accettazione
Si può essere sicuri che una User Story è stata completamente implementata, quando i criteri di accettazione si dimostrano essere stati rispettati. Ma cosa sono i criteri di accettazione?
Con criteri di accettazione in riferimento ad una storia utente si intende definire i parametri che dimostrano che i risultati chiave della storia utente sono stati raggiunti.
I parametri a cui stiamo facendo riferimento sono le W-Questions (Who? What? Why? When? Where? Ecc.).
Queste permettono di capire se una User Story è efficace e risponde a tutte le possibili esigenze cognitive del lettore.
I criteri di accettazione sono, dunque, dei test che vengono applicati alla storia utente per verificarne l’adeguatezza in base allo scopo di impiego. Particolare attenzione in questo contesto deve essere concessa all’individuazione e alla valorizzazione delle parole chiave, ovvero l’uso di verbi, aggettivi e sostantivi pertinenti.
Il principio INVEST
Un modo per testare l’efficacia della vostra User Story è ricorrere al principio formulato da William Wake. Anche INVEST è un acronimo e sta per:
- Indipendent: la User Story possiede una sua individualità ed è indipendente dalle altre storie utente.
- Negotiable: il contenuto è implementabile e continuamente migliorabile. Esso si sviluppa da una collaborazione tra il lettore e i realizzatori della storia. Essa può andare, così, più nel dettaglio mano a mano che si avanza nella sua realizzazione e nel suo testing.
- Valuable: la storia utente deve essere di valore per il cliente. Essa deve offrire al lettore un vantaggio o un beneficio e deve fornire indicazioni su come raggiungerlo.
- Estimable: la valutabilità di una User Story è il presupposto e la conditio-sine-qua-non del suo essere negoziabile. La valutabilità di una storia utente dipende anche dalla sua taglia: quanto più una storia è lunga, tanto più sarà difficile da valutare. Non solo, questo criterio dipende anche dall’esperienza del team di lavoro: un gruppo di esperti sarà in grado di valutare con più abilità ed immediatezza una storia rispetto a dei novelli del mestiere.
- Small: le storie utente di qualità tendono ad essere brevi. Tra l’altro, più una storia è breve, più risulta valutabile.
- Testable: la User Story ha criteri di accettazione e può essere testata. Se una storia è difficilmente testabile dagli utenti, questo può significare che essa non è chiara abbastanza, o che non offre un beneficio di valore al lettore.
In fin dei conti, tutti i punti del principio INVEST servono a valutare la qualità di una storia utente e, anche, a pilotarne la realizzazione perché essa risulti efficace. Attenersi ai punti proposti in questo modello di svolgimento può fare la differenza nel determinare il successo della vostra User Story!
La gerarchia delle User Stories
Come palesato dal principio INVEST, le storie utente dovrebbero essere indipendenti tra loro. Tuttavia, nella pratica, accade spesso che esistano delle interdipendenze tra varie User Stories. La dipendenza delle storie utente può essere di tipo diverso. Ad esempio, essa può avvenire a livello contenutistico, tecnico, normativo o regolamentare, temporale, e così via.
L’esistenza di interdipendenze tra le User Stories non è spesso evidente, ecco perché è utile utilizzare uno User Story Mapping, al fine di scovarle e rimuoverle.
User vs. Epic Stories
Esiste una differenziazione di base all’interno della macrocategoria delle storie utente. Infatti, in base alla portata dei benefici forniti da queste ultime al lettore, le User Stories possono essere anche assumere la denominazione di Epic Stories.
La differenziazione di queste due categorie non è omogenea e sempre uguale a se stessa. Ciò significa che non esiste uno standard riconosciuto in base al quale una storia viene classificata automaticamente come User o Epic.
In linea generale, tuttavia, si può definire una Epic Story come una storia utente che possegga un alto grado di pregnanza tecnica e specialistica. Le Epic Stories, normalmente, infatti, descrivono le funzionalità in modo assolutamente dettagliato, tecnico e specifico.
User Stories: perché utilizzarle?
Una User Story è uno strumento pratico e poco dispendioso a livello di costi e di tempo da dedicarvi. Ad essa sono, tuttavia, legati diversi vantaggi, come :
- Soprattutto se dettagliata, una User Story può supportare lo sviluppo iterativo di un sistema;
- È di facile comprensione e di immediata ricezione;
- Può essere creata, modificata e sostituita rapidamente.
Al giorno d’oggi le storie utente sono uno degli strumenti prediletti per formulare e discutere le funzionalità di un prodotto o servizio. Ecco perché conoscerne i meccanismi ed imparare a padroneggiarli è fondamentale per un’implementazione mirata di un qualsivoglia sistema.