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 stesso è una novità per Lei, inizi con la domanda: «Che cos’è una user story?». In sintesi, 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 giro 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 accesso 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 rientrano 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 è “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ò tutta la riflessione che il formato stesso è destinato a stimolare.

La nuova versione:

In qualità di membro del progetto che rientra a metà sprint, desidero accedere alla bacheca che stavo visualizzando l’ultima volta prima di effettuare l’accesso, in modo da non doverla ricercare ogni mattina.

Ecco una persona, un momento e un vantaggio che qualcuno potrebbe valutare rispetto ad 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, indicando al team che l’intervallo di tempo rilevante è di ore, non di secondi. Un ruolo ben scelto riesce a sintetizzare 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: si definisce una posizione relativa al prodotto (gli account sono facoltativi) e si espone il vantaggio in tutta onestà: l’esitazione ostacola i primi acquisti. Storie così chiare mettono in luce fin da subito eventuali disaccordi: 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’epopea, non una storia.

La riscrittura (un estratto):

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

L’epopea si trasforma in una serie di parti come questa, ciascuna delle quali verificabile e di dimensioni sufficientemente ridotte.

Dispositivi mobili

7. Modalità offline

In qualità di tecnico sul campo, desidero che la scheda di lavoro di oggi venga caricata senza connessione, in modo da poter continuare a lavorare negli scantinati 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 integrante. Quando, in fase di perfezionamento, qualcuno chiede: «Quanto “offline” è davvero “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 avvisi 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 da cui intende proteggere è 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 vera e propria user story tecnica: lo sviluppatore è un utente esterno reale con i propri obiettivi, non il team che inserisce se stesso nella frase. Gli utenti delle API, gli autori di plugin e gli operatori di turno superano tutti tale criterio.

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 ridurre la frequenza delle richieste 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 dell’applicazione del formato delle user story a un contesto per cui non è stato concepito, un caso trattato nell’articolo “Quando le user story sono lo strumento sbagliato”.

La riscrittura (non si tratta, volutamente, di una user story):

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 modificare il core del checkout. L’operazione sarà completata 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 articolo 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 piano annuale, desidero che sulla mia fattura sia indicato lo sconto che mi era stato comunicato, 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’individuazione dei bug garantisce che la velocità rifletta fedelmente l’effettivo impiego della capacità; il capitolo dedicato agli story point 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 che descriva 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 a durata prestabilita: indagare per due giorni, presentare 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 interesse concreto che consente a questa richiesta di competere con le attività rivolte ai clienti per l’assegnazione di uno slot nello sprint, anziché essere automaticamente scartata.

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 trasferibili. Una buona clausola di vantaggio 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 realizzato, 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.

La stessa persona, lo stesso istinto, ma ora si adatta a uno sprint e un tester sa quando il lavoro è terminato.

Ciò che accomuna le persone di valore

Riveda i dodici criteri 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 che regge a un sincero «perché?». Nessuno di essi contiene indicazioni di implementazione, né cerca di essere esaustivo. È a questo che servono i criteri di accettazione e il dialogo di perfezionamento.

I quattro casi problematici falliscono esattamente in due modi, 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. Redigete la vostra prossima serie di storie seguendo il modello, poi sottoponetele al team utilizzando il Planning Poker e osservate quali di 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.” Questa frase identifica una persona specifica, una funzionalità dal punto di vista di quella persona e il motivo per cui vale la pena pianificare il lavoro. Questa struttura in tre parti (ruolo, obiettivo, vantaggio) 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 clausola “in modo che” con un vantaggio che regga a un sincero “perché?”. Successivamente, aggiunga 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 autentico è “il team”, abbandonate le formalità e redigete un semplice documento tecnico 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 ciò che è stato deciso nel corso della discussione. Se l’elenco dei criteri supera i cinque, significa che la storia è in realtà composta da più storie, e i criteri indicano dove è opportuno suddividerla.

Approfondimenti

• Stima agile: la guida completa. Qui troverete tutte le informazioni necessarie.
• Che cos’è una user story? Il formato, le tre “C” e la checklist INVEST alla base di ciascuno degli esempi sopra riportati.
• Modello di user story e criteri di accettazione. Un modello pronto 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 in sala.