Template di User Story con criteri di accensione (Gratuito)

Un template di user story svolge due funzioni. Fa sì che ogni storia risponda alle stesse tre domande (chi, cosa, perché) e fornisce al team un posto fisso per annotare come sapranno che la storia è completata. Questa pagina ti offre entrambe: il formato a riga singola, un template completo della scheda da copiare, criteri di accettazione in tre formati, una definizione di pronto e di completato ed esempi pratici.

Se sei nuovo alle user story, inizia con la nostra guida su come scrivere user stories, poi torna qui per il template.

Il template di user story a riga singola

La maggior parte dei team utilizza il formato nato dal team Connextra a Londra nel 2001 e reso popolare dal libro di Mike Cohn User Stories Applied (la sua panoramica sulle user story è un buon punto di partenza):

Come [tipo di utente], desidero [un'azione o una capacità], in modo da [un vantaggio o un risultato].

Ogni parte svolge una funzione specifica:

• “Come” nomina un tipo reale di utente, come un acquirente alla prima esperienza, un amministratore di account o un paziente ricorrente. “Come utente” non dice nulla al team. Se hai delle personae, usa i loro nomi.
• “Desidero” descrive ciò che l'utente fa o ottiene, con le sue parole. Non dovrebbe descrivere la soluzione (“un menu a tendina”, “una cache Redis”); lascia spazio al team per trovare la migliore.
• “In modo da” enuncia il valore. Questa è la parte più spesso omessa e quella che conta di più: è come il team può proporre un'opzione più semplice che ottiene lo stesso risultato e come il product owner decide la priorità.

Tieni presente che la frase non è il requisito. Ron Jeffries ha descritto una storia come tre cose: la scheda, la conversazione e la conferma (le 3 C). Un template aiuta con la scheda e la conferma (i criteri di accettazione); nulla sostituisce la conversazione.

Il template completo della scheda di user story

La riga singola è sufficiente per un post-it. In uno strumento di backlog di solito servono alcuni campi in più affinché la storia possa essere classificata, stimata e testata. Questi sono i campi che riteniamo utili; elimina quelli che il tuo team non legge mai.

Mantieni “Contesto e note” breve: se si trasforma in una pagina di specifica, la storia è probabilmente un epic e necessita di essere suddivisa (il nostro guida alla story mapping mostra come).

Modello di user story pronto per la copia

Incolla questo nel campo descrizione di un issue Jira o Linear, in un modello di database Notion, o nella riga di intestazione di un foglio di calcolo. Sostituisci il testo tra parentesi quadre ed elimina le righe che non utilizzi.

• ID: [PROJECT-000]
• Titolo: [Verbo + oggetto, ad esempio “Esporta fatture in CSV”]
• Storia: Come [tipo di utente], desidero [azione o capacità], in modo da [beneficio].
• Contesto: [Perché è importante ora; link a ricerche, ticket di supporto o metriche]
• Criteri di accettazione: [da 3 a 7 condizioni testabili, in formato elenco o Given/When/Then]
• Fuori scope: [Cosa questa storia non copre deliberatamente]
• Design: [Link al frame o al prototipo]
• Dipendenze: [Altre storie, servizi o decisioni]
• Priorità: [Must / Should / Could, o posizione nella backlog]
• Stima: [Punti o dimensione, compilata dal team]
• Domande aperte: [Qualsiasi cosa che debba essere risolta prima dell'inizio dello sprint]

La riga “Fuori scope” evita discussioni: scrivere “non include il reset via SMS” sulla carta è meglio che scoprire nella sprint review che qualcuno aveva assunto che lo facesse.

Cosa sono i criteri di accettazione e chi li scrive

I criteri di accettazione sono le condizioni che una storia deve soddisfare per essere accettata dal product owner. Descrivono il comportamento osservabile dal punto di vista dell'utente, non come funziona il codice. Buoni criteri sono:

• Testabili: qualcuno può dire sì o no senza interpretare. “Veloce” non è testabile; “i risultati appaiono entro due secondi” lo è.
• Specifici per questa storia: le regole che si applicano a ogni storia (codice revisionato, deployato in staging) appartengono alla definition of done, non qui.
• Privi di dettagli di implementazione: indica cosa succede, non quale componente o tabella lo rende possibile.
• Onesti riguardo al fallimento: almeno un criterio copre input non validi, assenza di rete o permessi mancanti.
• Pochi: da tre a sette criteri è un intervallo sano. Più di dieci di solito significa che la storia dovrebbe essere suddivisa.

Il product owner è responsabile dei criteri, ma non dovrebbe scriverli da solo. Il pattern più affidabile è una breve conversazione di raffinamento tra product, uno sviluppatore e un tester (spesso chiamati “three amigos”): qual è il valore, come verrà costruito, come potrebbe rompersi.

Formato 1: criteri di accettazione in elenco

Un elenco semplice di condizioni. È il formato più veloce da scrivere e leggere, e funziona bene per storie semplici e per team che testano manualmente.

Storia: Come cliente ricorrente, desidero reimpostare la mia password via email, in modo da poter accedere nuovamente al mio account senza contattare il supporto.

• La schermata di login ha un link “Password dimenticata?” che apre il modulo di reimpostazione.
• L'invio di un indirizzo email registrato invia un link di reimpostazione entro un minuto.
• Il link di reimpostazione funziona una volta e scade dopo 30 minuti.
• La nuova password deve rispettare le regole esistenti per le password e il modulo indica quale regola non è stata soddisfatta.
• Dopo un reset riuscito, tutte le altre sessioni per quell'account vengono disconnesse.
• L'invio di un indirizzo non registrato mostra lo stesso messaggio di conferma di uno registrato, in modo che il modulo non riveli chi possiede un account.

Utilizza la checklist quando il comportamento è semplice. Il suo limite è che nasconde lo stato iniziale e l'ordine degli eventi, che il formato successivo rende esplicito.

Formato 2: Criteri di accettazione Given/When/Then (Gherkin)

Given/When/Then proviene dallo sviluppo guidato dal comportamento, che Dan North ha descritto con Chris Matts in Introducing BDD. Ogni scenario definisce un contesto iniziale (Given), un'azione (When) e un risultato atteso (Then). Gherkin è la versione strutturata di questo linguaggio utilizzata da Cucumber e strumenti simili, in modo che gli scenari scritti in questo modo possano diventare test automatizzati con poche modifiche.

Ecco la stessa storia di reset della password come tre scenari, inclusi due percorsi non riusciti.

Scenario 1: reset con un link valido

• Dato che ho un account registrato a anna@example.com
• E ho richiesto un reset della password
• Quando apro il link di reset entro 30 minuti e inserisco una nuova password che rispetta le regole
• Allora la mia password viene modificata
• E sono connesso
• E le mie altre sessioni vengono disconnesse

Scenario 2: il link è scaduto

• Dato che ho richiesto un reset della password più di 30 minuti fa
• When apro il link di reimpostazione
• Then vedo un messaggio che indica che il link è scaduto
• E mi viene offerto un pulsante per inviare un nuovo link

Scenario 3: l'indirizzo email non è registrato

• Dato che non esiste alcun account per sam@example.com
• Quando richiedo un reset della password per sam@example.com
• Allora vedo lo stesso messaggio di conferma che vede un utente registrato
• E nessuna email viene inviata

Quando uno scenario deve essere eseguito con più input (ad esempio, un elenco di password che devono essere rifiutate), lo Scenario Outline di Gherkin consente di scriverlo una volta ed elencare gli input in una tabella di esempi.

Mantieni Gherkin leggibile: un comportamento per scenario e scrivi in modo dichiarativo (“Quando richiedo un link di reset”) piuttosto che clic per clic (“Quando clicco il pulsante Invia”), in modo che lo scenario sopravviva a un ridisegno.

Formato 3: Criteri di accettazione basati su regole

Per le storie che riguardano principalmente regole aziendali (prezzi, idoneità, validazione, permessi), enuncia le regole direttamente e aggiungi scenari solo per le combinazioni complesse.

Storia: Come acquirente, voglio applicare un codice sconto al checkout, in modo da pagare il prezzo promozionale.

• Regola 1: un codice per ordine.
• Regola 2: un codice percentuale si applica solo al sottototale del prodotto, non alla spedizione o alle tasse.
• Regola 3: un codice con spesa minima si applica solo quando il sottototale, prima dello sconto, raggiunge il minimo.
• Regola 4: i codici scaduti o esauriti vengono rifiutati con un messaggio che spiega il motivo.
• Regola 5: rimuovere articoli in modo che il sottototale scenda sotto il minimo rimuove il codice e mostra un avviso.

È possibile mescolare formati in un'unica storia. Un pattern comune è utilizzare le regole per la logica e due o tre scenari Given/When/Then per i casi che le persone sono più propense a fraintendere.

Definizione di pronto vs definizione di completato

I criteri di accettazione sono specifici per una singola storia. La definizione di pronto e la definizione di completato sono accordi a livello di team che si applicano a ogni storia.

Il Scrum Guide definisce la definizione di completato come la descrizione formale dello stato dell'Incremento quando soddisfa le misure di qualità richieste per il prodotto. La definizione di pronto non fa parte di Scrum; è una pratica adottata da molti team per impedire che lavori parzialmente compresi entrino in uno sprint (vedi il glossario dell'Agile Alliance su definizione di pronto e definizione di completato).

Esempio di definizione di pronto

• La storia segue il template e il campo “in modo che” è compilato.
• I criteri di accettazione sono scritti e revisionati da product, sviluppo e testing.
• I design sono collegati, oppure il team ha concordato che non ne servono.
• Le dipendenze sono completate o pianificate.
• Il team l'ha stimata e si adatta a uno sprint.

Esempio di definizione di completato

• Tutti i criteri di accettazione sono superati.
• Il codice è stato revisionato e unito alla branch principale.
• I test automatizzati coprono il nuovo comportamento e l'intera suite passa.
• I controlli di base sull'accessibilità vengono superati (uso della tastiera, etichette, contrasto).
• È stato distribuito in ambiente di staging e il product owner lo ha accettato.

Considera la definizione di pronto come un elenco di controllo per il raffinamento, non come un ostacolo. Se un team rifiuta ogni storia che non soddisfa un singolo punto, il lavoro rallenta e la conversazione che la storia doveva avviare non avviene mai.

Esempi pratici

Altre due storie da prodotti di tipo diverso. Per altre quaranta, consulta il nostro esempi di user story.

SaaS: invita un collega (elenco di controllo)

Come amministratore dello spazio di lavoro, voglio invitare un collega via email, in modo che possa vedere i nostri progetti senza che io debba condividere le mie credenziali di accesso.

• Gli amministratori vedono un pulsante “Invita” nella pagina dei membri; gli altri ruoli non lo vedono.
• L'amministratore può scegliere il ruolo (Membro o Amministratore) prima dell'invio.
• L'email di invito arriva entro un minuto e il link è valido per sette giorni.
• L'invito a un indirizzo che è già un membro mostra un messaggio invece di inviare un secondo invito.

E-commerce: salva un articolo per dopo (Given/When/Then)

Come acquirente che non è pronto all'acquisto, voglio spostare un articolo dal carrello a un elenco salvato, in modo da poterlo trovare di nuovo senza che influisca sul totale del mio ordine.

• Dato che sono autenticato e ho due articoli nel carrello
• Quando scelgo “Salva per dopo” su un articolo
• Allora quell'articolo viene spostato nel mio elenco salvato
• E il totale del mio carrello viene ricalcolato senza di esso
• Dato che non sono autenticato
• Quando scelgo “Salva per dopo”
• Allora mi viene chiesto di effettuare l'accesso e l'articolo viene salvato una volta fatto

Utilizzare il modello in Jira, Linear, Notion o un foglio di calcolo

In Jira, usa il tipo di problema Story e incolla il modello nella descrizione (oppure mantieni i criteri di accettazione in un campo dedicato se il tuo amministratore ne ha aggiunto uno). In Linear, salvalo come modello di problema. In Notion, inseriscilo in un modello di database in modo che le nuove pagine del backlog si apriscano precompilate. Un foglio di calcolo con una riga per storia funziona per un primo backlog o un workshop, ma passa a un tracker non appena più persone lo modificano. Qualunque sia lo strumento, mantieni il modello abbastanza breve da essere compilato.

Stesura di storie e criteri di accettazione con l'AI

I modelli linguistici sono bravi a creare una prima bozza di storie e criteri. Un prompt che funziona:

Sei un product manager. Per la funzionalità descritta di seguito, scrivi storie utente nel formato “Come [utente], voglio [azione], in modo da [beneficio]”. Per ogni storia, aggiungi da 3 a 6 criteri di accettazione in forma Given/When/Then, includendo almeno un percorso di errore. Elenca separatamente eventuali assunzioni e domande aperte. Funzionalità: [descrizione della funzionalità, degli utenti e di eventuali vincoli].

Poi rivedi la bozza come qualsiasi altro input:

• L'utente è un segmento reale con cui hai parlato, o un generico “utente”?
• Il modello ha inventato regole di business, limiti o numeri? Sostituiscili con i tuoi.
• I percorsi di errore sono quelli che i tuoi utenti incontrano realmente? Una bozza non sostituisce mai la conversazione di raffinamento.

Domande frequenti

Vuoi che un team trasformi le tue storie in software funzionante? Porta il tuo backlog, o anche solo l'idea, e ti aiuteremo a modellarlo in storie di dimensione sprint e a svilupparlo. Vedi i nostri piani di sviluppo mensili.