Come scrivere le user story (con esempi e criteri di accettazione)

Una user story è una breve descrizione di una funzionalità dal punto di vista dell'utente: "Come [tipo di utente], voglio [obiettivo] in modo che [motivo]." Sotto scrivi i criteri di accettazione, poche condizioni specifiche che devono essere vere perché la storia si consideri completata. Mantieni ogni storia abbastanza piccola da essere costruita e verificata in un colpo solo, e scrivi i criteri in modo che chiunque possa controllarli.

Le user story sono diventate popolari nei team di sviluppo agile, ma sono altrettanto utili quando costruisci da solo con un generatore di app AI. Una buona storia è un buon prompt.

Il formato

Una user story ha tre parti:

Come [chi], voglio [cosa] in modo che [perché].

Chi è un tipo specifico di utente: un visitatore alla prima volta, un socio che paga, un receptionist di una clinica, un amministratore. Non "l'utente".
Cosa è ciò che vuole fare, con parole sue. Non come funziona la schermata.
Perché è il risultato a cui tiene. È la parte che la gente salta, e quella che ti impedisce di costruire la cosa sbagliata.

Esempio:

Come socio della palestra, voglio annullare una prenotazione di un corso dal telefono in modo che qualcuno in lista d'attesa possa prendere il mio posto e non mi venga addebitata una penale per la mancata presenza.

Il "perché" ti dice due cose che il "cosa" non diceva: deve funzionare sul telefono, e sono coinvolte la lista d'attesa e le regole della penale.

Criteri di accettazione

La storia dice cosa si vuole. I criteri di accettazione dicono quando è fatto. Devono essere abbastanza specifici da far concordare due persone su se ciascuno passa o no.

Un modo comune per scriverli è Dato / Quando / Allora:

Dato una situazione di partenza
Quando l'utente fa qualcosa
Allora questo è il risultato

Per la storia della prenotazione in palestra:

Dato che ho una prenotazione tra più di 12 ore, quando tocco Annulla e confermo, allora la prenotazione viene rimossa e vedo "Prenotazione annullata".
Dato che annullo una prenotazione e il corso ha una lista d'attesa, quando l'annullamento viene salvato, allora la prima persona in lista ottiene il posto e un'email.
Dato una prenotazione tra meno di 12 ore, quando tocco Annulla, allora vedo che si applica una penale per annullamento tardivo prima di confermare.
Dato che sono su uno schermo di larghezza da telefono, allora il pulsante Annulla è visibile senza scorrere di lato.

Va bene anche una semplice checklist, purché ogni voce sia verificabile. "Annullare è facile" non è verificabile. "Annullare richiede al massimo due tocchi dall'elenco delle prenotazioni" lo è.

Passo dopo passo: scrivere una buona storia

Passo 1: Parti da un utente reale e da un problema reale

Scegli un tipo di utente e qualcosa che oggi gli crea difficoltà. Se hai fatto interviste ai clienti, usa le loro parole. "Dimentico sempre di annullare e mi addebitano" è un punto di partenza migliore di "aggiungi funzione di annullamento".

Passo 2: Scrivi la storia in una riga

Compila il modello. Se non riesci a scrivere un "in modo che" convincente, chiediti se la funzionalità serve davvero.

Passo 3: Aggiungi da tre a sei criteri di accettazione

Copri prima il caso di successo principale, poi le variazioni importanti: un ruolo diverso, uno stato vuoto, un limite, un errore. Se ne scrivi più di sei, la storia è probabilmente troppo grande.

Passo 4: Annota cosa è fuori dal perimetro

Una riga fa risparmiare molti scambi: "Fuori dal perimetro: rimborsi per i corsi a pagamento; amministratori che annullano per conto dei soci." Impedisce alla storia di crescere mentre la costruisci.

Passo 5: Verificala con INVEST

INVEST è una checklist comune per le buone storie. Una storia dovrebbe essere:

Lettera	Significa	Test rapido
I	Indipendente	Si può costruire senza aspettare un'altra storia
N	Negoziabile	Descrive il bisogno, non un design fisso
V	Di valore	Un utente se ne accorgerebbe se venisse rilasciata
E	Stimabile	Puoi indovinare a grandi linee quanto è grande
S	Piccola	Costruita e verificata in una sessione
T	Verificabile	Ogni criterio di accettazione può essere controllato

Non serve valutare ogni storia. È utilissima quando una storia ti sembra sbagliata e vuoi capire perché.

Esempi buoni e cattivi

Storia debole	Problema	Storia migliore
Come utente, voglio una dashboard.	Nessun utente specifico, nessun motivo, non verificabile	Come titolare di negozio, voglio vedere gli ordini e il fatturato di oggi in una sola schermata in modo che capisca a colpo d'occhio se la giornata va bene.
Come amministratore, voglio che il database abbia una colonna di stato.	Descrive l'implementazione, non un bisogno	Come amministratore, voglio segnare gli ordini come spediti in modo che i clienti smettano di scrivermi per chiedere dove sono.
Come cliente, voglio gestire il mio account.	Troppo grande: copre molte funzionalità	Come cliente, voglio cambiare il mio indirizzo email in modo che le ricevute arrivino nella mia nuova casella.
Come visitatore, voglio che il sito sia veloce.	Non è una storia; è una qualità di cui tutti hanno bisogno	Scrivilo come criterio su ogni storia, oppure come obiettivo di prestazioni separato.

Come dividere una storia troppo grande

Le storie grandi sono dove i progetti si bloccano. Modi comuni per dividerle:

Per ruolo utente. I soci annullano le proprie prenotazioni; lo staff annulla quelle di chiunque.
Per passaggio del flusso. Sfoglia i corsi; prenota un corso; ricevi un promemoria.
Prima il caso semplice. Annulla un corso gratuito ora; gestisci penali e rimborsi in una storia successiva.
Per variazione dei dati. Supporta prima una sede, poi più sedi.
Percorso felice, poi gli errori. Costruiscilo funzionante, poi aggiungi la gestione per corsi al completo, abbonamenti scaduti e così via.

Ogni pezzo deve comunque essere qualcosa che un utente può usare e notare.

Usare le user story come prompt

Una user story con criteri di accettazione è molto vicina a un buon prompt per un generatore di app AI. Dà all'AI il chi, il cosa, il perché e una definizione di completato. Invia una storia per messaggio:

Come socio della palestra, voglio annullare una prenotazione di un corso dal telefono in modo che qualcuno in lista d'attesa possa prendere il mio posto. Criteri di accettazione:

Annulla compare su ogni prenotazione in Le mie prenotazioni, con un passaggio di conferma.

Annullare più di 12 ore prima del corso rimuove semplicemente la prenotazione.

Meno di 12 ore prima, mostra "Si applica una penale di 5 $ per annullamento tardivo" prima di confermare, e registra la penale sulla prenotazione.

Se il corso ha una lista d'attesa, la prima persona ottiene il posto e un'email.

Funziona su uno schermo di larghezza da telefono. Fuori dal perimetro: rimborsi, annullamenti da parte dello staff per conto dei soci. Costruisci questo, poi verifica ogni criterio nell'anteprima e dimmi quali passano.

Puoi anche chiedere all'AI di abbozzare le storie partendo da un'idea grezza, e poi modificarle tu:

Ecco l'idea della mia app: [due o tre frasi]. Scrivi le user story per una prima versione, raggruppate per tipo di utente, ognuna con da 3 a 5 criteri di accettazione Dato/Quando/Allora. Segna quali sono essenziali per il lancio e quali possono aspettare.

Leggi e modifica sempre il risultato. L'AI non conosce i tuoi utenti; li conosci tu.

I criteri di accettazione fanno anche da piano di test. Quando la storia è costruita, ripercorri tu ogni criterio. La nostra guida su come testare la tua app prima del lancio si basa su questo.

Dove si inseriscono le user story con gli altri documenti

Un documento dei requisiti di prodotto descrive l'intero prodotto: il problema, gli utenti, il perimetro. Le user story sono i pezzi dettagliati al suo interno. Vedi come scrivere un PRD con l'AI.
Una segnalazione di bug descrive qualcosa che non funziona rispetto a una storia già costruita. Vedi come scrivere una buona segnalazione di bug.
Un MVP è l'insieme più piccolo di storie che offre il valore principale. Vedi cos'è un MVP.

Errori comuni

"Come utente…" Troppo vago. Indica il tipo reale di utente.
Saltare il "in modo che". Senza il motivo non puoi fare compromessi sensati.
Scrivere la soluzione invece del bisogno. "Voglio un menu a tendina" blocca un design prima che qualcuno ci abbia pensato.
Criteri non verificabili. "Facile", "veloce" e "intuitivo" sono desideri, non criteri.
Storie che in realtà sono epic. "Gestisci il mio account" sono dieci storie.
Scrivere tutte le storie in anticipo. Scrivi in dettaglio le prossime poche; tieni le altre come frasi brevi finché non ci arrivi.

Storie in Mythex

Su Mythex, la modalità Piano è un buon posto per trasformare un'idea in storie: l'agente discute l'approccio prima di modificare qualsiasi cosa. Quando una storia è pronta, passa a Costruisci e incollala, una storia per messaggio. Dopo ognuna, /test può cliccare nell'anteprima e verificare il flusso, e puoi annullare qualsiasi risposta con Ripristina a questo punto se è andata nella direzione sbagliata. Vedi prompt efficaci nella documentazione, e la nostra guida su come scrivere prompt per i generatori di app AI.

Checklist per le user story

Indica un tipo specifico di utente
Descrive un bisogno, non un design
Include un vero motivo "in modo che"
Ha da tre a sei criteri di accettazione verificabili
Copre almeno un caso limite o un errore
Dichiara cosa è fuori dal perimetro
È abbastanza piccola da essere costruita e verificata in una sola sessione
I criteri sono controllati uno per uno dopo la costruzione

Domande

Qual è il formato di una user story?

Il modello più comune è: Come [tipo di utente], voglio [un obiettivo] in modo che [un motivo]. Segue l'elenco dei criteri di accettazione, cioè le condizioni brevi che devono essere vere perché la storia si consideri completata.

Cosa sono i criteri di accettazione?

I criteri di accettazione sono condizioni specifiche e verificabili che definiscono quando una user story è completa. Spesso si scrivono in formato Dato / Quando / Allora: data una situazione di partenza, quando l'utente fa qualcosa, allora si verifica un determinato risultato.

Quanto deve essere grande una user story?

Abbastanza piccola da poter essere costruita e verificata in una sola sessione, e comunque utile da sola. Se una storia ha più di cinque o sei criteri di accettazione o copre diverse schermate, dividila per ruolo utente, per passaggio del flusso, o per caso semplice con i casi limite dopo.

Le user story sono utili quando costruisco con l'AI?

Sì. Una user story con criteri di accettazione è quasi un prompt ideale: dice per chi è la funzionalità, di cosa ha bisogno e come verificare esattamente che funzioni. Inviare una storia per messaggio mantiene anche le modifiche dell'AI piccole e facili da verificare.