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 il mio indirizzo e-mail, in modo da poter visualizzare la cronologia dei miei ordini.” Non si tratta, volutamente, di una specifica. La scheda rappresenta la promessa di avviare un dialogo, 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 si basa sulle storie. Sono proprio queste che il planning poker utilizza per stabilire 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 sia ben gestita 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], affinché [vantaggio].

Tre slot, e ciascuno 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 come è strutturato il sistema. «Desidero reimpostare la mia password» è un obiettivo. «Desidero un microservizio per la reimpostazione della password» è una decisione progettuale che assume tale 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 l’argomentazione alla base dell’inserimento della carta nel programma. Se nessuno è in grado di portarla a termine, il lavoro non ha ragion d’essere, 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.

La scheda è un simbolo: una o due frasi, volutamente brevi. Le sue dimensioni costituiscono una caratteristica distintiva: non può fisicamente 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 storia durante il perfezionamento del backlog: i casi limite e ciò che è esplicitamente escluso dall’ambito del progetto. I team che tralasciano questa fase e considerano la scheda come il requisito vero e proprio si ritrovano con il peggio di entrambi i mondi: un documento troppo scarso su cui basare 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 discussione. 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 del 2003 di Bill Wake rappresenta tuttora il modo più rapido per verificare se una storia sia pronta per essere sviluppata. Una buona storia è:

• Indipendente: pianificabile autonomamente, senza dover includere altre tre storie nel sprint.
• Negoziabile: la scheda invita a un dialogo; l’ambito può ancora evolversi. Una storia in cui ogni dettaglio è fissato in modo definitivo è un requisito che si maschera da storia.
• Significativo: la proposizione 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 stimare la portata comporta un’incognita; esegua un spike per individuarla.
• Piccolo: rientra in uno sprint con margine di tempo. In caso contrario, dividetelo.
• Verificabile: è possibile definire criteri di accettazione che risultino superati o non superati. “La pagina sembra più veloce” non soddisfa questo criterio; “i risultati si caricano in meno di un secondo” lo soddisfa.

I concetti di “stimabile” e “piccolo” sono il punto 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 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 la discussione 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 costituisce una promessa di implementazione. La story definisce il risultato; spetta al team decidere come ottenerlo. Quando una story viene presentata con la 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. Lo descriva come un semplice lavoro tecnico con un risultato ben definito: cosa smetterà di funzionare o subirà rallentamenti 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 nativa più adeguata rispetto a una story adattata a posteriori. Il capitolo dedicato agli story point illustra quando vengono assegnati i punti alle story.
• 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’unico aspetto 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 costituisce l’unità di stima. Una volta redatta, il percorso segue questa guida: il team ne discute, ne determina la dimensione in story points utilizzando il planning poker, ne verifica la conformità alla definizione di pronto e, qualora il voto non dovesse convergere, la suddivide. Una storia ben strutturata accelera ciascuno di questi passaggi, ed è proprio questo il motivo pratico per cui è importante prestare attenzione al formato.

Per osservare il formato applicato, il capitolo dedicato agli esempi di user story illustra sedici storie commentate, sia positive che negative. Per scriverne una propria, si inizi 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, e i dettagli vengono definiti quando il team perfeziona e quantifica il 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 ne trae 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 un 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 uno story sia pronto per essere sviluppato. Gli ultimi tre criteri hanno il peso maggiore nella pratica: uno story che il team non è in grado di stimare, che non rientra in uno sprint o che nessun test è in grado di confermare è uno story che non è ancora pronto.

In quali casi è opportuno non utilizzare le 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 attività 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.

Approfondimenti

• 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 dettagliato che arriva fino alla stima.
• Epic vs storia vs attività: dove si colloca la storia nella gerarchia e quale livello viene indicato.
• Suddivisione delle user story: cosa fare quando una user story non supera il “test della brevità”.