Che cos’è una user story?

Una user story è una breve descrizione, redatta in un linguaggio semplice, di una modifica, raccontata dal punto di vista della persona che ne trae beneficio: “In qualità di cliente abituale, desidero effettuare l’accesso con la mia e-mail, in modo da poter visualizzare la cronologia dei miei ordini.” Non si tratta, di proposito, di una specifica. La scheda rappresenta la promessa di avviare una conversazione, mentre i dettagli vengono definiti quando il team perfeziona la storia, ne redige i criteri di accettazione e ne valuta la portata.

Tutto il resto di questa guida ruota attorno alle storie. Sono proprio queste che il planning poker utilizza per determinare le dimensioni, a cui si attribuiscono gli story point e che vengono suddivise quando la stima non converge. Un team che redige storie inadeguate fornirà stime errate, indipendentemente da quanto bene conduca la sessione, poiché è proprio dai dati di input che hanno origine i problemi.

Il formato: ruolo, obiettivo, vantaggio

La forma classica risale a Connextra, un team XP londinese, intorno al 2001:

In qualità di [ruolo], desidero [obiettivo], in modo che [vantaggio].

Tre slot, e ognuno svolge una funzione specifica.

• Il ruolo indica chi riceve il valore. «In qualità di utente» è l’errore più comune in questo formato: una storia che potrebbe riguardare chiunque è una storia su cui nessuno ha effettivamente verificato. Indichi la persona specifica: il cliente abituale, lo sviluppatore di integrazioni.
• L’obiettivo è la funzionalità dal punto di vista dell’utente, che descrive ciò che la persona fa piuttosto che il modo in cui il sistema è realizzato. «Voglio reimpostare la mia password» è un obiettivo. «Voglio un microservizio per la reimpostazione della password» è una decisione progettuale che ne riprende la forma.
• Il vantaggio è la clausola che i team eliminano per prima, ed è proprio quella che garantisce alla scheda il suo posto nel backlog. Il «in modo che» rappresenta la motivazione per cui la storia deve essere inserita nel programma. Se nessuno è in grado di portarla a termine, il lavoro non ha senso, e mettere per iscritto tale clausola consente di rendersene conto prima dell’inizio dello sprint, anziché dopo.

Biglietto, conversazione, conferma

Ron Jeffries ha sintetizzato il funzionamento delle storie in tre “C”, e l’ordine in cui sono presentate è importante.

Il biglietto è un promemoria: una o due frasi, volutamente concise. La sua dimensione è una caratteristica fondamentale: fisicamente non può contenere un requisito completo, il che rende inevitabile il passaggio alla fase successiva (C).

La conversazione è il contesto in cui il requisito prende effettivamente forma. Il team e il Product Owner discutono approfonditamente la questione durante il perfezionamento del backlog: i casi limite e ciò che è esplicitamente escluso dall’ambito di progetto. I team che tralasciano questa fase e considerano la scheda come il requisito stesso si ritrovano con il peggio di entrambi i mondi: un documento troppo scarso su cui basarsi per lo sviluppo e l’assenza di dialogo perché «è già stato messo per iscritto».

La conferma costituisce i criteri di accettazione: le condizioni di superamento o fallimento che indicano se il lavoro completato soddisfa quanto concordato durante la conversazione. Il capitolo dedicato al modello di user story illustra i due formati utilizzabili, mentre il capitolo dedicato ai criteri di accettazione ne approfondisce la stesura.

La lista di controllo INVEST

La lista di controllo di Bill Wake del 2003 rimane il modo più rapido per verificare se una storia è pronta per essere sviluppata. Una buona storia è:

• Indipendente — pianificabile autonomamente, senza dover coinvolgere altre tre storie nello sprint.
• Negoziabile — la scheda invita al dialogo; l’ambito può ancora evolversi. Una storia in cui ogni dettaglio è fissato è un requisito che si maschera da storia.
• Significativo — la clausola con «in modo che» regge di fronte a un sincero «perché?».
• Quantificabile — il team è in grado di attribuirgli un valore numerico. Una story di cui nessuno riesce a valutare l’entità comporta un’incognita; esegua un spike per individuarla.
• Piccolo — rientra in uno sprint con un margine di tempo. Se così non fosse, dividetelo.
• Verificabile — è possibile definire criteri di accettazione che determinino il superamento o il fallimento del test. “La pagina sembra più veloce” comporta il fallimento del test; “i risultati si caricano in meno di un secondo” comporta il superamento del test.

“Storie di dimensioni adeguate” e “storie di piccole dimensioni” sono i punti in cui le storie si collegano al resto di questa guida. Un ampio divario nei voti nel planning poker è solitamente indice di un fallimento della fase INVEST che emerge in ritardo: la storia era negoziabile in modi che nessuno aveva preso in considerazione, oppure era troppo ampia perché qualcuno potesse coglierne la totalità.

Cosa non è una user story

Non è un’attività. Una storia offre qualcosa che l’utente può vedere; un’attività è un passo che il team compie per raggiungere tale obiettivo. “Accedi con l’indirizzo e-mail” è una storia. «Configurare l’archivio delle sessioni» è una delle sue attività. Il capitolo dedicato alla distinzione tra epica, storia e attività illustra la gerarchia e spiega perché i punti di valore appartengono esclusivamente al livello della storia.

Non si tratta di un documento di requisiti. Un requisito deve essere completo prima dell’inizio dei lavori. Una storia deve essere sufficiente per avviare il dialogo e nulla più. Giudicare le storie in base agli standard dei requisiti (“è troppo vaga!”) significa non cogliere l’essenza del progetto: la vaghezza è uno spazio riservato al giudizio del team.

Non si tratta di una promessa di implementazione. La storia definisce il risultato; spetta al team decidere come raggiungerlo. Quando una storia viene presentata con una soluzione già prestabilita, la parte negoziabile del modello INVEST viene meno.

Quando le user story non sono lo strumento adeguato

Questo formato presenta dei limiti, e fingere il contrario compromette la credibilità agli occhi di chi deve scrivere le frasi più complesse. In alcune frasi non compare il soggetto:

• Lavoro approfondito sulla piattaforma. «In qualità di sviluppatore, desidero aggiornare il framework, affinché il framework venga aggiornato» non aggiunge nulla rispetto a quanto già espresso nel titolo del ticket. Descrivete il lavoro in termini puramente tecnici, indicando un risultato concreto: cosa smetterà di funzionare o subirà un rallentamento se ciò non avviene, e cosa risulterà più semplice una volta realizzato.
• Bug con causa nota. Una segnalazione di difetto (comportamento previsto, comportamento effettivo, passaggi per riprodurre il problema) rappresenta una forma più appropriata rispetto a una story adattata a posteriori. Il capitolo sui punti story illustra quando ai bug vengono assegnati dei punti.
• I picchi di ricerca. Un picco è costituito da una domanda e da un intervallo di tempo definito, e il suo risultato è la conoscenza. Costringerlo a rientrare nello schema “ruolo-obiettivo-beneficio” oscura l’unica cosa che conta: ciò che il team deve imparare.
• Attività di conformità. Non è possibile negoziare l’ambito di applicazione con un’autorità di regolamentazione. Il requisito è il requisito; lo si deve riportare tale e quale.

Ciò che accomuna tutti questi casi è la disciplina, non la struttura della frase: una motivazione chiara del perché il lavoro sia importante e una definizione verificabile di “completato”. Se si mantengono questi elementi, il formato ha svolto la sua funzione anche laddove non sia applicabile.

Dove le storie incontrano la stima

Una storia è l’unità di stima. Una volta redatta, il percorso segue questa guida: il team la discute, ne valuta la dimensione in story points utilizzando il planning poker, la verifica rispetto alla definizione di pronto e la suddivide qualora il voto non dovesse convergere. Una storia ben strutturata accelera ciascuna di queste fasi: questo è il motivo pratico per cui è importante prestare attenzione al formato.

Per vedere come viene applicato il formato, il capitolo dedicato agli esempi di user story illustra sedici storie commentate, sia positive che negative. Per scriverne una vostra, partite dal modello.

Domande frequenti

Che cos’è una user story?

Una user story è una breve descrizione, redatta in un linguaggio semplice, di una modifica, raccontata dal punto di vista della persona che ne trae beneficio: «In qualità di cliente abituale, desidero effettuare l’accesso con la mia e-mail, in modo da poter visualizzare la cronologia dei miei ordini». Si tratta volutamente non di una specifica. La scheda funge da spunto per una conversazione, mentre i dettagli vengono definiti quando il team perfeziona e valuta l’entità del lavoro.

In cosa consiste il formato della user story?

Il formato classico è ruolo-obiettivo-vantaggio: «In qualità di [ruolo], desidero [obiettivo], affinché [vantaggio]». Il ruolo indica chi ottiene il valore, l’obiettivo definisce la funzionalità dal punto di vista dell’utente, mentre il beneficio costituisce la motivazione per cui il lavoro va pianificato. Se nessuno è in grado di completare la clausola «in modo che», la storia non ha motivo di essere inserita nel backlog.

Quali sono le tre “C” delle user story?

Scheda, discussione, conferma. La scheda funge da promemoria ed è volutamente troppo succinta per contenere l’intero requisito. È durante la discussione che il requisito prende effettivamente forma, attraverso il processo di affinamento con il team. La conferma consiste nei criteri di accettazione che stabiliscono, con un giudizio di “superato” o “non superato”, se il lavoro completato rispetta quanto discusso.

Cosa significa l’acronimo INVEST?

Indipendente, negoziabile, di valore, stimabile, di piccole dimensioni, verificabile. Si tratta della lista di controllo elaborata da Bill Wake per stabilire se una story sia pronta per essere sviluppata. Nella pratica, gli ultimi tre criteri hanno il peso maggiore: una story che il team non è in grado di stimare, che non rientra in uno sprint o per la quale non esiste alcun test in grado di confermarne la validità è una story che non è ancora pronta.

In quali casi è opportuno non ricorrere alle user story?

Quando il formato aggiunge formalità anziché chiarezza. Il lavoro approfondito sulla piattaforma, le correzioni di bug con causa nota, i requisiti di conformità e i picchi di ricerca trovano tutti una forma più adeguata nel contesto nativo. Mantenete la clausola sui benefici e i criteri di accettazione; evitate la formula “in qualità di sviluppatore, desidero” quando nella frase non è presente alcun utente.

Letture correlate

• Stima agile: la guida completa — il punto di riferimento per tutto ciò che riguarda questo argomento.
• Esempi di user story — sedici user story commentate, comprese quelle che non funzionano e le relative motivazioni.
• Modello di user story e criteri di accettazione — il modello, le sue varianti e un esempio concreto che illustra l’intero processo fino alla stima.
• Epic vs storia vs attività — dove si colloca la storia nella gerarchia e a quale livello si fa riferimento.
• Suddivisione delle user story — cosa fare quando una user story non supera il “test della semplicità”.