Marzo 2, 2020 - di Giuseppe Costanza
Cosa sono le User Story e come si scrivono
In un precedente articolo – Come stabilire le priorità nello sviluppo di prodotto – ho spiegato il concetto di Product Backlog, che ho definito come un elenco ordinato di funzionalità che si intende sviluppare. Ho anche accennato al contenuto del Backlog, ovvero le User Story.
In questo articolo mi focalizzerò sulle User Story. Vi spiegherò il perché del loro nome, come si scrivono e condividerò alcuni esempi di User Story.
Devo ammettere che la prima volta che ho sentito parlare di User Story, ho fatto fatica a credere che fosse una tecnica utile per migliorare lo sviluppo di prodotti software. Il nome mi ha fatto pensare al titolo per un film fantasy anni 80!
Superato il pregiudizio sul nome ho compreso la logica che ci sta dietro e, dopo qualche test fallito, ho capito che sono uno strumento fondamentale per sviluppare prodotti digitali.
Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 100 pagine su Agile, Team Cross-funzionale, Scrum/Kanban, Backlog, etc. ti presento Agile Starter Kit, una cartella condivisa su Google Drive pensata per gli eroi come te che stanno iniziando il proprio viaggio nel Digital Product Management.
Cosa è una User Story?
Le User Story sono le specifiche da condividere con il team di sviluppo per stabilire cosa deve essere sviluppato. Ti starai chiedendo perché non chiamarle semplicemente Specifiche Tecniche oppure Requisiti Funzionali. Il concetto più interessante che introducono le User Story è quello di mettere l’utilizzatore del nostro prodotto (lo User) al centro dell’attenzione durante il processo di sviluppo. Pari importanza è data anche all’identificazione del bisogno che ogni funzionalità promette di soddisfare (la storia).
Questo approccio si differenzia dai metodi di sviluppi più tradizionali nei quali il responsabile di prodotto condivide con il team un elenco di requisiti tecnici o funzionali. Quello che spesso succede è che la motivazione per cui una funzionalità viene richiesta si perde nella catena di comando o, ancora peggio le specifiche vengono travisate come accade nel gioco del telefono senza fili.
Questa vignetta spiega molto bene cosa può succedere quando manca una sana comunicazione nel processo di sviluppo di un software.
Caratteristiche di una User Story
Le User Story hanno la caratteristica di descrivere:
- L’utente a cui ci stiamo rivolgendo
- il bisogno che vogliamo soddisfare
- il motivo per cui dobbiamo soddisfarlo.
Un po’ di esempi pratici renderanno tutto molto più chiaro!
Ma, prima di partire con gli esempi, voglio dirvi quali sono per me le 2 caratteristiche essenziali delle User Story: chiarezza e confronto.
Mi piace molto la definizione di User Story di Mike Cohn: ogni User Story è la promessa di una conversazione. Per Mike quello che c’è scritto nella User Story non è molto importante, è solo un promemoria per innescare una discussione con tutto il team.
I dettagli d’implementazione arriveranno quindi solo dopo che tutti nel team hanno chiaro quale valore vogliamo portare e a chi lo stiamo portando.
Come si scrivono le User Story
Passiamo alla pratica!
Le User Story hanno solitamente il seguente formato:
Come [descrizione dell’utente], voglio [funzionalità o azione] in modo che [obiettivo o valore per l'utente].
Proviamo ora a riempire questo schema con un esempio pratico.
Facciamo finta che stiamo sviluppando un portale di e-commerce e vogliamo aggiungere una specifica per la funzione di accesso al proprio account. È una funzionalità abbastanza standard che si trova su tutti gli e-commerce, può sembrare ovvio il motivo per cui esiste e il modo in cui implementarla, ma scrivendola a mo’ di User Story dovrete farvi delle domande interessanti: per chi è utile tale funzione? Perché è utile?
Come utente registrato voglio poter effettuare il log-in in modo che posso accedere alle mie informazioni personali.
Analisi della nostra prima User Story.
Come prima cosa descriviamo quale utente stiamo servendo. A prima vista si potrebbe pensare che l’utente è unico per un prodotto. In realtà ogni prodotto ha una varietà di utenti con diversi intenti.
In un e-commerce possiamo sicuramente distinguere tra utenti alla prima visita, utenti registrati, utenti che hanno fatto 1 o più acquisti, e così via. Inoltre molti prodotti hanno alle spalle un servizio e spesso una parte dello sviluppo è dedicata ad utenti interni come per esempio il servizio clienti.
Una funzionalità, inoltre, può servire a più tipologie di utenti e avere più di una finalità. Nell’esempio fatto sopra il log-in serve sia per accedere alle proprie informazioni ma anche per proteggere i propri dati dall’accesso di altri utenti. Il formato tipico delle User Story ci impone di fare una scelta e decidere le priorità. Quando scrivete una User Story focalizzatevi sempre sulla funzione più importante. Scrivete User Story separate per dettagliare i bisogni differenti. Può creare ridondanza ma vi permetterà di condividere con chiarezza quali sono le priorità.
Facciamo un altro esempio. Nel nostro e-commerce vogliamo avere un modulo di contatto per permettere agli utenti di scrivere al nostro Supporto Tecnico. A chi serve questa funzione? Perché gli serve?
Come utente alla prima visita voglio poter inviare una mail al supporto per segnalare un malfunzionamento del sito.
Come utente alla prima visita voglio poter inviare una mail al supporto per ricevere informazioni sui costi di spedizione.
Come utente registrato voglio poter inviare una mail al supporto per segnalare un malfunzionamento del sito.
Potremmo scrivere decine di User Story per descrivere il modulo di contatto, ma ti consiglio di focalizzare l’attenzione sui casi più importanti per il business e considerare gli altri come spunti per futuri miglioramenti. La metodologia Agile ci dice infatti di rilasciare poco e spesso per portare valore agli utenti il prima possibile e per validare l’utilità di quanto sviluppato.
Come entrare nel dettaglio
Nel paragrafo precedente abbiamo visto come scrivere le prime User Story, abbiamo già un ottimo punto di partenza per una bella riunione con il team che si occuperà di svilupparle.
La riunione servirà a porre domande e portare chiarezza. Per esempio “quali campi deve avere il modulo di contatto?”, “come fa l’utente a trovarlo?”
Questi sono dettagli che vanno aggiunti all’interno della User Story, solitamente si definiscono Criteri di Accettazione. I Criteri di Accettazione sono fondamentali anche per poter verificare se la funzionalità sviluppata rispecchia ciò che era stato deciso. Vi accorgerete che il 90% delle volte ciò che viene implementato non rispecchia quanto era previsto!
La gerarchia delle User Story e le Storie Epiche
Uno dei problemi nell’uso delle User Story è la mancanza di contesto attorno alla storia. Esistono diversi stratagemmi per risolvere.
Luca Gherardi, Group Product Manager da Tripadvisor, che ci racconta la sua esperienza in merito.
“Nella mia esperienza anche le migliori user-story non possono essere efficaci se non inserite nel giusto contesto. Nei miei team in Tripadvisor raggruppiamo le User Story all’interno di ‘epic’ per poterle contestualizzare. Immaginate le epic come dei traguardi intermedi.
Nell’esempio di Giuseppe potremmo chiamare la nostra Epic “Funzionalità di login”. All’interno di quest’ultima andremo poi a inserire le varie User Stories come “Frontend – processo login”, “Backend- processo login”, “Processo di recupero password” e così via fino ad aver completato la nostra funzionalità di login.
Per non perdere di vista le varie Epic, andiamo a nostra volta a raggrupparle all’interno di “iniziative”. Tornando al nostro esempio possiamo chiamare la nostra iniziativa “Sito e-commerce – primo rilascio”. All suo interno inseriremo tutte le Epic che riteniamo indispensabili per il rilascio del nostro sito.”
Ogni team ha il suo stile
La cosa che mi piace di più dei metodi Agile è la sua flessibilità, le User Story non hanno una struttura precisa che tutti devono seguire. Di ogni strumento devi comprendere il senso e poi puoi applicarlo come meglio credi.
Per rafforzare questo concetto ho fatto un piccolo esperimento. Ho chiesto ad alcuni dei nostri Eroi (i Product Manager della community di ProductHeroes) di aggiungere i loro Criteri di Accettazione alla mia User Story di esempio, il risultato come vedete cambia molto da persona a persona.
Esempi di Criteri di Accettazione dalla community
User Story:
Come utente registrato voglio poter effettuare il login per poter accedere alle mie informazioni personali
Criteri di Accettazione di Sara
- Abilitazione area personalizzata per ogni utente registrato
- Area personalizzata contiene le informazioni generali, password e modalità di pagamento preferite
- Attraverso l’area personalizzata è possibile modificare in tutto o in parte le mie informazioni e le mie preferenze
- Attraverso l’area personalizzata posso cancellare il mio profilo
Criteri di Accettazione di Matteo:
- Scenario: L’utente prova a loggarsi con credenziali valide.
DATO che sono un utente non loggato e mi trovo sulla pagina di login
QUANDO inserisco “Username” e “Password” corretti e clicco il bottone di login
ALLORA il sistema mi logga.
- Scenario: L’utente prova a loggarsi con credenziali errate.
DATO che sono un utente non loggato e mi trovo sulla pagina di login
QUANDO inserisco “Username” e “Password” errati e clicco il bottone di login
ALLORA il sistema non mi logga e mostra il messaggio di errore relativo
Criteri di Accettazione di Adriano:
- Scenario: l’utente accede al sito mediante dati validi.
- L’utente (non loggato) accede alla pagina principale e al modulo di accesso.
- Inserisce le proprie credenziali (campi obbligatori “nome utente” e “password”).
- Per procedere, clicca sul bottone “Accedi” o utilizza un proprio account social precedentemente utilizzato per la registrazione.
- Il sistema lo fa accedere e direziona alla propria pagina personale.
- Mostra messaggio di errore qualora nome utente e/o password fossero errati (“nome utente e/o password errati. Riprova).
Ho scritto le User Story e le ho condivise con il team. E ora che si fa???
Luca Gherardi: “Immagino che a questo punto molti di voi si chiedano “cosa me ne faccio di tutte queste user stories”? Nella mia esperienza queste si rivelano fondamentali per determinare quanto tempo pensiamo d’impiegare per poterle realizzarle. Nel mio team parliamo anche di “metterle in faccia ai nostri consumatori”. Questo processo è chiamato anche “backlog grooming”. Nel caso in cui vi stiate domandando a cosa vi serva sapere la durata (a volte chiamata anche LOE – level of effort), la risposta è per il vostro processo di pianificazione! Pianificare la prossima sprint (o quantificare il backlog nel caso usiate un metodo Kanban) è parte fondamentale dei processi agile su cui potete leggere nell’articolo Le due metodologie Agile: Scrum e Kanban.“
Conclusioni
In questo articolo ho fatto un’introduzione alla scrittura delle User Story, la versione Agile delle specifiche funzionali. Mi auguro che gli esempi riportati e i contributi della community ti abbiamo aiutato a capire come passare dalla teoria alla pratica.
È importante chiarire che introdurre le User Story in un progetto di sviluppo già esistente non è per niente semplice. Il metodo sembrerà macchinoso e ridondante e saranno in tanti nel team a non vederne l’utilità. Il mio consiglio è di partire con un piccolo esperimento, non provare a riscrivere tutte le specifiche come User Story in 2 giorni! Parti da un progetto nuovo, meglio se di piccole dimensioni. Ricorda anche che la cosa più importante è capire il perché ha senso usare le User Story e adattare la sintassi a quella che funziona meglio per te e per il team.
Infine se dovessi avere dubbi puoi scrivere un commento, ti risponderemo!
Leave a comment