Esempi di user story: 16 storie commentate, positive e negative

Sedici esempi di user story, tratti dai settori in cui i team operano effettivamente: autenticazione, e-commerce, dispositivi mobili, API, bug e strumenti interni. Ciascuno di essi è corredato di note esplicative: non solo cosa dice la story, ma anche perché le clausole relative al ruolo e al beneficio sono fondamentali. Quattro di esse sono volutamente errate e vengono presentate accanto alle loro versioni corrette, poiché il modo più rapido per apprendere il formato è osservarne gli errori.

Se il formato in sé è nuovo per voi, iniziate con Che cos’è una user story? — in breve, ogni storia qui segue lo schema “In qualità di [ruolo], desidero [obiettivo], in modo che [vantaggio]”, e ogni storia ben formulata potrebbe passare direttamente alla fase di perfezionamento e a un ciclo di planning poker.

Autenticazione e account

1. Accesso

In qualità di cliente abituale, desidero effettuare l’accesso con la mia e-mail e la mia password, in modo da poter visualizzare la cronologia dei miei ordini.

Perché funziona: il ruolo è ben definito. L’espressione “cliente abituale” indica che questa persona possiede un account, ha già effettuato ordini in passato e ha un motivo per tornare — tre elementi che un progettista e un tester possono sfruttare. L’espressione “in qualità di utente” non avrebbe fornito alcuna di queste informazioni.

2. Reimpostazione della password

In qualità di utente con account bloccato, desidero reimpostare la mia password dalla schermata di accesso, in modo da poter accedere nuovamente al mio account senza dover contattare l’assistenza.

Perché funziona: la clausola relativa ai benefici indica un costo concreto. Ogni ripristino gestito dall’assistenza rappresenta un costo quantificabile, pertanto questa segnalazione può essere considerata prioritaria rispetto ad altre sulla base di dati concreti anziché di impressioni soggettive. Si noti ciò che la frase non include: la scadenza dei token, i limiti di frequenza, il modello di e-mail. Tali dettagli devono essere inseriti nei criteri di accettazione, redatti quando il team ne definirà i dettagli:

• Entro due minuti dalla richiesta riceverà un’e-mail di reimpostazione.
• Il link di reimpostazione scade dopo un’ora e può essere utilizzato una sola volta.
• Il modulo fornisce la stessa risposta indipendentemente dal fatto che l’indirizzo e-mail esista o meno (nessuna enumerazione degli account).

3. La storia circolare

In qualità di utente, desidero effettuare l’accesso per poter utilizzare l’app.

Perché non è corretto: ogni spazio è occupato, ma non viene espresso alcun contenuto. Il ruolo non è attribuito a nessuno in particolare e il beneficio ribadisce l’obiettivo; pertanto, la clausola “in modo che” potrebbe essere eliminata senza perdere alcuna informazione. Una storia come questa supera il controllo di formato, tralasciando però tutto il ragionamento che il formato stesso è destinato a stimolare.

La nuova versione:

In qualità di membro del progetto che rientra a metà sprint, vorrei accedere alla bacheca che avevo visualizzato l’ultima volta dopo aver effettuato l’accesso, in modo da non doverla ricercare ogni mattina.

Ecco una persona, un momento e un vantaggio che qualcuno potrebbe mettere a confronto con altre opportunità lavorative.

E-commerce

4. Persistenza del carrello

In qualità di acquirente che naviga sul sito durante la pausa pranzo, vorrei che il mio carrello conservasse gli articoli che ho selezionato quando tornerò stasera, in modo da non dover cercare di nuovo tutto da capo.

Perché funziona: il ruolo descrive uno scenario. «Navigare sul web durante la pausa pranzo» spiega perché i carrelli vengono abbandonati a metà del processo, il che indica al team che l’intervallo di tempo rilevante è di ore, non di secondi. Un ruolo ben scelto racchiude il contesto in una sola frase.

5. Procedura di pagamento per gli ospiti

Essendo un nuovo cliente, vorrei procedere al pagamento senza creare un account, in modo da poter completare l’acquisto prima di cambiare idea.

Perché funziona: parte da una posizione relativa al prodotto (gli account sono facoltativi) e ne illustra il vantaggio in tutta onestà: l’esitazione ostacola i primi acquisti. Storie così chiare mettono in luce fin da subito eventuali divergenze: se l’azienda desidera che ogni acquirente disponga di un account, tale discussione avrà luogo in fase di perfezionamento, non nella richiesta di pull.

6. Il personaggio che indossa un costume da fiaba

In qualità di acquirente, desidero una procedura di pagamento più rapida e intuitiva, in modo da migliorare il tasso di conversione.

Perché non funziona: per due motivi. «Più veloce, più pulito» non è una funzionalità che chiunque possa sviluppare o testare, e «migliora la conversione» è un vantaggio per l’azienda, non per l’acquirente: nessun acquirente desidera la conversione. Si tratta di un trimestre di lavoro condensato in una sola frase, il che lo rende un epico, non una storia.

La riscrittura (un estratto):

Quando effettuo un acquisto dal cellulare, vorrei che l’indirizzo di spedizione venisse compilato automaticamente in base al mio codice postale, in modo da poter completare la procedura di pagamento con una sola mano.

Il progetto epico si trasforma in un insieme di parti come questa, ciascuna delle quali è verificabile e sufficientemente piccola da poter essere gestita.

Cellulare

7. Modalità offline

In qualità di tecnico sul campo, vorrei che la scheda di lavoro di oggi si caricasse senza connessione, in modo da poter continuare a lavorare nei seminterrati e nelle zone senza copertura di rete.

Perché funziona: è il ruolo a determinare il requisito. Il personale d’ufficio non si accorge mai del supporto offline; i tecnici sul campo, invece, ne fanno parte a pieno titolo. Quando, durante la fase di perfezionamento, qualcuno chiede «quanto è “offline” l’offline?», il ruolo ha già fornito la risposta: ovunque il lavoro li porti.

8. Preferenze relative alle notifiche

In qualità di abbonato che riceve tre notifiche push al giorno, vorrei poter scegliere per quali tipi di avviso ricevere le notifiche, in modo da non dover più disattivare le notifiche dell’intera app.

Perché funziona: il beneficio identifica la modalità di fallimento che la storia previene. Gli utenti non si lamentano del volume delle notifiche; disattivano i suoni dell’app e se ne vanno in silenzio. Una storia che identifica il comportamento silenzioso contro cui si schiera è una storia su cui il team può discutere in modo sincero.

API e attività tecniche

9. Impaginazione

In qualità di sviluppatore di integrazioni, desidero che le risposte all’endpoint /events siano paginate, in modo che la mia sincronizzazione notturna non vada in timeout in presenza di account di grandi dimensioni.

Perché funziona: questa è una user story tecnica autentica: lo sviluppatore è un utente esterno reale con obiettivi propri, non il team che inserisce se stesso nella frase. Gli utenti delle API, gli autori di plugin e gli operatori di turno superano tutti questo test.

10. Limitazione della frequenza

In qualità di utente dell’API, desidero ricevere una risposta 429 con un’intestazione Retry-After quando raggiungo il limite di frequenza, in modo che il mio client possa sospendere l’operazione anziché interrompere l’intero processo.

Perché funziona: l’obiettivo è sufficientemente preciso da costituire di per sé il primo criterio di accettazione, e rimane comunque un cosa, non un come — nulla in questo caso impone l’implementazione del limitatore.

11. Il refactoring sotto mentite spoglie

In qualità di sviluppatore, desidero rifattorizzare il modulo dei pagamenti, in modo che il codice risulti più chiaro.

Perché non funziona: il ruolo è rappresentato dal team, l’obiettivo è un’attività piuttosto che un risultato, e il termine “più pulito” non è verificabile. Si tratta del formato della user story applicato a un contesto per cui non è stato concepito — un caso trattato in Quando le user story sono lo strumento sbagliato.

La riscrittura (non è una user story, di proposito):

Ridurre il vincolo di dipendenza dal fornitore nel modulo dei pagamenti, in modo che sia possibile aggiungere un nuovo fornitore di servizi di pagamento senza intervenire sul codice di base del checkout. L’obiettivo sarà raggiunto quando: l’interfaccia del fornitore sarà stata estratta, i due fornitori esistenti funzioneranno tramite tale interfaccia e la suite di test di integrazione supererà i test senza modifiche.

Un semplice argomento tecnico con un risultato ben definito è sempre preferibile a una storia ricca di dettagli.

Si tratta di un bug o di una funzionalità?

12. L’insetto che è una storia

In qualità di cliente con un abbonamento annuale, desidero che sulla mia fattura sia indicato lo sconto che mi era stato promesso, in modo che l’ufficio contabilità possa effettuare la riconciliazione senza dover aprire un ticket di assistenza.

Perché funziona: la causa è nota e la correzione ha un ambito ben definito, quindi questa storia si comporta come qualsiasi altra: le vengono assegnati dei criteri, una dimensione e uno slot nello sprint. L’assegnazione di punti alle attività relative ai bug garantisce che la velocità rifletta fedelmente l’effettivo impiego della capacità; il capitolo sui punti storia illustra questo argomento in modo esaustivo.

13. L’errore che non è tale

I clienti segnalano sporadicamente di aver ricevuto un addebito doppio. Non è possibile riprodurre il fenomeno in modo affidabile.

Perché non si tratta di una storia: non vi è alcun margine per formulare promesse. Una frase del tipo «ruolo-obiettivo-beneficio» («In qualità di cliente, desidero che non mi venga addebitato due volte…») sarebbe vera ma inutile, e qualsiasi stima non farebbe altro che misurare una speranza. La mossa giusta è uno spike: indagare per due giorni, comunicare quanto appreso, quindi redigere la vera storia per la correzione.

Strumenti interni e reportistica

14. Strumenti di supporto

In qualità di addetto all’assistenza tramite chat in tempo reale, desidero visualizzare gli ultimi cinque tentativi di accesso del cliente, in modo da poter distinguere a colpo d’occhio un caso di password dimenticata da un account bloccato.

Perché funziona: gli utenti interni sono pur sempre utenti. Il vantaggio si misura in secondi per ticket, ed è proprio questo tipo di risultato concreto che consente a questa attività di competere con il lavoro rivolto ai clienti per aggiudicarsi uno slot nello sprint, anziché essere automaticamente esclusa.

15. Esportazioni

In qualità di responsabile del team, desidero esportare il rapporto dello sprint in formato CSV, in modo da poter condividere i risultati con le parti interessate che non dispongono di un account.

Perché funziona: la clausola “in modo che” definisce implicitamente l’ambito di applicazione. La condivisione al di fuori dello strumento è l’obiettivo, il che esclude soluzioni quali dashboard integrate nell’app e regole in noiosi file CSV esportabili. Una buona clausola di beneficio svolge il lavoro di progettazione a titolo gratuito.

16. L’epopea della visibilità

In qualità di manager, desidero disporre di un pannello di controllo che riassuma tutte le attività svolte dal team, in modo da avere una visione d’insieme.

Perché non funziona: «tutto» non è un ambito e la «visibilità» non è un risultato — nulla di tutto ciò può essere sviluppato, testato o quantificato. Dietro una descrizione come questa si nasconde una domanda concreta che al responsabile non è ancora stata posta.

La nuova versione:

In qualità di responsabile della consegna incaricato di preparare la riunione di aggiornamento del lunedì, desidero che l’obiettivo dello sprint di ciascun team e il relativo stato (rosso/giallo/verde) siano riportati su un’unica pagina, in modo da poter segnalare le attività bloccate senza dover contattare singolarmente ogni responsabile.

Stessa persona, stesso istinto, ma ora si adatta a uno sprint e un tester sa quando è terminato.

Ciò che accomuna le persone di valore

Riveda i dodici che funzionano. Ciascuno di essi indica una persona sufficientemente specifica da poter esprimere un’opinione, enuncia un obiettivo che tale persona riconoscerebbe e comporta un vantaggio in grado di reggere a un sincero «perché?». Nessuno di essi contiene indicazioni di implementazione, né cerca di essere esaustivo: a questo servono i criteri di accettazione e il dialogo di affinamento.

Le quattro storie difettose presentano due tipi di errori ben precisi, il che è incoraggiante: o il beneficio è circolare (nessuno ha verificato il perché) oppure l’ambito è di portata epica (nessuno ha verificato quanto sia ampio). Entrambi i fallimenti emergono nel momento stesso in cui il vostro team cerca di stimare la storia; ecco perché le sessioni di valutazione individuano le storie non valide più rapidamente di qualsiasi linea guida di scrittura: un’ampia dispersione dei voti costituisce il messaggio di errore di questo formato. Scriva la sua prossima serie di storie seguendo il modello, poi le sottoponga al team utilizzando il planning poker e verifichi quali tra esse raggiungono un consenso.

Domande frequenti

Qual è un esempio di user story?

“In qualità di cliente abituale, desidero effettuare l’accesso con la mia e-mail e la mia password, in modo da poter visualizzare la cronologia dei miei ordini.” Essa identifica una persona specifica, una capacità espressa nei termini di quella persona e il motivo per cui vale la pena pianificare il lavoro. Questa struttura in tre parti (ruolo, obiettivo, beneficio) costituisce il classico formato della user story.

Come si scrive una buona user story?

Indichi un ruolo specifico anziché “un utente”, definisca l’obiettivo come un’azione compiuta dalla persona piuttosto che come un elemento presente nel sistema e concluda la frase con “in modo che” indicando un vantaggio in grado di reggere a un sincero “perché?”. Aggiunga poi i criteri di accettazione, poiché la frase che descrive la storia funge da spunto di conversazione, non da requisito.

È possibile redigere un documento tecnico sotto forma di user story?

A volte. Se l’“utente” è reale — uno sviluppatore di integrazioni che utilizza la vostra API, un operatore di turno — il formato funziona così com’è. Se l’unico ruolo concreto è “il team”, abbandonate la forma convenzionale e redigete una semplice voce tecnica con un risultato ben definito e criteri di accettazione. La disciplina rimane la stessa; la struttura della frase non deve necessariamente cambiare.

I bug dovrebbero essere redatti sotto forma di user story?

Un bug con una causa nota e una soluzione chiara può esserlo, e segnalarlo garantisce l’affidabilità della velocità. Un bug che nessuno riesce a riprodurre non può esserlo: non vi è alcun margine per formulare una promessa, quindi una story sarebbe solo un’ipotesi accompagnata da una clausola sui benefici. Stabilite innanzitutto un intervallo di tempo per l’indagine, poi redigete la vera story in base a quanto emerso.

Quanto deve essere dettagliata una user story?

Una frase che descrive la storia, seguita da tre a cinque criteri di accettazione. La frase dà il via alla discussione; i criteri sintetizzano quanto deciso durante la discussione. Se l’elenco dei criteri supera i cinque, significa che la storia è composta da più storie distinte e che i criteri indicano dove è opportuno suddividerla.

Letture correlate

• Stima agile: la guida completa — il punto di riferimento per tutto ciò che riguarda questo argomento.
• Che cos’è una user story? — il formato, le tre “C” e la checklist INVEST alla base di ogni esempio sopra riportato.
• Modello di user story e criteri di accettazione — un modello da copiare e incollare e un esempio dettagliato che illustra l’intero processo fino alla stima.
• Suddivisione delle user story — come gestire gli epic nascosti negli esempi 6 e 16.
• Esempi di stima agile — la serie correlata: come si svolge effettivamente la valutazione delle dimensioni di queste storie durante le riunioni.