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

Sedici esempi di user story commentate relative ad autenticazione, e-commerce, dispositivi mobili, API e bug, con le versioni errate affiancate alle loro revisioni, in modo che la differenza risulti evidente.

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 riviste, poiché il modo più rapido per apprendere il formato è osservarne gli errori.

Se il formato in sé è una novità per Lei, inizi con Che cos’è una user story?. In sintesi, ogni user story qui segue lo schema “In qualità di [ruolo], desidero [obiettivo], in modo che [vantaggio]”, e ogni user story 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 utilizzando 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 nessuno di questi elementi.

2. Reimpostazione della password

In qualità di utente che non riesce ad accedere, 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 vantaggi indica un costo concreto. Ogni ripristino gestito dall’assistenza comporta un costo monetario 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 menziona: 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 perfeziona la segnalazione:

  • 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 (senza enumerazione degli account).

3. La storia circolare

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

Perché non è corretto: ogni spazio è occupato, ma non viene espresso alcun contenuto. Il ruolo non è quello di una persona in particolare e il vantaggio 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 è chiamato a stimolare.

La nuova versione:

In qualità di membro del progetto che rientra a metà sprint, desidero accedere direttamente 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 altri lavori.

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. L’espressione «navigare durante la pausa pranzo» spiega perché i carrelli vengono abbandonati a metà del percorso di acquisto, indicando al team che il lasso di tempo rilevante è di ore, non di secondi. Un ruolo ben scelto racchiude il contesto in una sola frase.

5. Procedura di pagamento come ospite

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. Una descrizione così chiara mette 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 «il miglioramento della conversione» rappresenta un vantaggio per l’azienda, non per l’acquirente. Nessun acquirente desidera la conversione. Si tratta di un intero trimestre di lavoro condensato in una sola frase, il che la rende un epico, non una storia.

La riscrittura (un estratto):

Quando effettuo un acquisto dal mio telefono, 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.

Il progetto epico si trasforma in un insieme di parti come questa, ciascuna delle quali verificabile e di dimensioni sufficientemente ridotte.

Dispositivi mobili

7. Modalità offline

In qualità di tecnico sul campo, vorrei che la scheda di lavoro di oggi venisse caricata senza bisogno di una 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 integrante. Quando, in 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 con gli account di grandi dimensioni.

Perché funziona: questa è una user story tecnica valida: lo sviluppatore è un utente reale ed esterno con obiettivi propri, non il team che inserisce se stesso nella frase. Gli utenti delle API, gli autori di plugin e gli operatori di reperibilità 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, intendo 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 concetto di “più pulito” non è verificabile. Si tratta dell’applicazione del formato delle user story 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 processo di 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’errore che è una storia

In qualità di cliente con un piano annuale, desidero che sulla mia fattura sia indicato lo sconto che mi era stato preventivato, 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 sui punti storia illustra tale argomentazione in modo esaustivo.

13. L’errore che non è tale

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

Perché non si tratta di una storia: non vi è spazio per alcuna promessa. 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 è un 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 operatore dell’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 uno di 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 storia di competere con il lavoro rivolto ai clienti per un posto 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. Condividere al di fuori dello strumento è l’obiettivo, il che esclude soluzioni quali dashboard integrate nell’app e regole in noiosi file CSV portabili. Una buona clausola di vantaggio svolge il lavoro di progettazione a titolo gratuito.

16. L’epopea della visibilità

In qualità di responsabile, 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. Alla base di una storia come questa si cela una domanda concreta che al manager non è ancora stata posta.

La nuova versione:

In qualità di responsabile della consegna incaricato di preparare la riunione di aggiornamento del lunedì, desidero che gli obiettivi di 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 il lavoro è terminato.

Ciò che accomuna le persone di valore

Riveda i dodici punti 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 sull’implementazione, né cerca di essere esaustivo. È a questo che servono i criteri di accettazione e la conversazione di raffinamento.

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, ed è per questo che 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 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 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 anziché come un elemento presente nel sistema e concluda la frase con “in modo che” indicando un vantaggio che regga a un sincero “perché?”. Successivamente, alleghi i criteri di accettazione, poiché la frase della 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 la forma convenzionale 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’accuratezza della velocità. Un bug che nessuno riesce a riprodurre non può esserlo: non vi è alcun margine per fare promesse, quindi una story sarebbe solo un’ipotesi accompagnata da una clausola sui benefici. Si definisca innanzitutto un intervallo di tempo per l’indagine, quindi si rediga la vera e propria story in base ai risultati ottenuti.

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 durante la discussione. Se l’elenco dei criteri supera i cinque, la storia si è trasformata in più storie, e i criteri indicano dove è opportuno suddividerla.

Approfondimenti