Generatore di user story

In breve: una user story è un requisito di una frase, scritto dal punto di vista dell’utente: chi ha bisogno di cosa e perché. Con due o tre criteri di accettazione Dato che / Quando / Allora, una stima e una priorità MoSCoW, uno sviluppatore può prenderla in carico senza una riunione di chiarimento. Il generatore offre il modello, cinque set di esempi, un controllo INVEST e un CSV che Jira importa come ticket di tipo Story.

Lo strumento è pensato per founder, product owner e analisti funzionali che vogliono un backlog ordinato prima di coinvolgere un fornitore. Storie scritte bene sono anche la base più rapida per una stima: se stai pianificando lo sviluppo di un MVP o una collaborazione più lunga di product engineering, inviaci il backlog e riceverai una stima entro un giorno lavorativo.

Il generatore funziona in quattro passaggi e tutti i dati restano nel tuo browser:

1. Prodotto. Dai un nome al prodotto o al rilascio, scegli story point o taglie a T-shirt e scrivi una Definition of Done comune.
2. Set. Scegli un punto di partenza: negozio online, consegna di cibo, app fitness, account SaaS o marketplace, otto storie ciascuno. Oppure parti da una lista vuota.
3. Storie. Modifica ruoli, azioni, valori, criteri, stime, priorità ed epic.
4. Controllo. Rivedi gli avvisi INVEST ed esporta in CSV per Jira, DOCX, Markdown o PDF.

In questa versione non c’è generazione con l’IA: riscrivi un modello o un set, così le storie descrivono il tuo prodotto.

Com’è fatta una buona user story?

Una buona user story indica un ruolo preciso, una sola azione e un valore difendibile davanti a chi approva il budget: «Come [ruolo], voglio [azione] per [valore]». Ecco un esempio completo per un negozio online:

Storia: Come cliente abituale, voglio ripetere un ordine passato con un clic per non dover ricomporre il carrello da zero.

• Dato che ho effettuato l’accesso e ho un ordine completato, quando premo «Ordina di nuovo», allora tutti gli articoli disponibili finiscono nel carrello nelle stesse quantità.
• Dato che un articolo di quell’ordine è esaurito, quando premo «Ordina di nuovo», allora gli altri articoli vengono aggiunti e vedo quale è stato saltato.
• Dato che il carrello contiene già degli articoli, quando riordino, allora i nuovi articoli si aggiungono senza sostituire quelli presenti.

Stima: 3 story point (M). Priorità: Should. Epic: Ordini.

Se non riesci a scrivere la parte «per…», chiediti se la funzionalità serve davvero.

Come si scrivono i criteri di accettazione con Dato che / Quando / Allora?

Ogni criterio copre uno scenario: Dato che descrive lo stato prima dell’azione, Quando l’azione stessa, Allora un risultato che chiunque può verificare senza chiederti nulla. È lo schema Given / When / Then del BDD, detto anche DATO-QUANDO-ALLORA. Parti dal caso principale e aggiungi ciò che di solito si rompe in produzione: dati vuoti, errori, permessi mancanti, connessione assente. Da tre a cinque criteri è una misura ragionevole; se ne servono più di sei, probabilmente le storie sono due.

I criteri di accettazione non sono la Definition of Done. I criteri appartengono a una singola storia; la Definition of Done vale per tutte («code review fatta, test verdi, rilascio in staging»). Il QA può trasformare ogni riga in un caso di test.

Cosa significa INVEST e cosa controlla il generatore?

INVEST è una verifica di qualità in sei punti. Il generatore segnala ciò che può rilevare da solo; il resto si chiarisce con il team.

Come si stimano e si mettono in priorità le user story?

La scala 1, 2, 3, 5, 8 confronta le storie tra loro: non sono ore. Le taglie a T-shirt sono più rapide per un primo giro; il generatore le salva come punti (XS = 1, S = 2, M = 3, L = 5, XL = 8), così la colonna di Jira resta numerica.

MoSCoW divide il backlog in Must, Should, Could e Won’t (non questa volta). Per il primo rilascio tieni il gruppo Must abbastanza piccolo da consegnare, da solo, qualcosa di utilizzabile. Won’t serve a ricordare cosa avete deciso di lasciare fuori.

Come si importano le user story in Jira?

Scarica «CSV per Jira», poi in Jira apri Sistema → Importazione da sistema esterno → CSV e mappa le colonne. Ogni riga è una storia:

• Summary: l’azione, abbastanza breve per una card della board;
• Description: la frase «Come… voglio… per…» con i criteri numerati;
• Issue Type: sempre Story;
• Story Points: da 1 a 8;
• Epic Link: il nome dell’epic; crea prima le epic o usa chiavi esistenti;
• Labels: la priorità MoSCoW (moscow-must, moscow-should…) e, con le taglie a T-shirt, la taglia.

Nei progetti gestiti dal team mappa l’epic sul campo Parent invece che su Epic Link.

Dove si collocano le user story rispetto a PRD e capitolato tecnico?

Le storie descrivono il comportamento, i documenti intorno danno il contesto. Obiettivi, perimetro, rischi e requisiti non funzionali vanno nel documento dei requisiti di prodotto, che puoi impostare con il template PRD. Lì indichi anche la conformità GDPR che ti aspetti dal fornitore: non è una singola storia. Se affidi lo sviluppo all’esterno, allega il backlog a un capitolato tecnico per la richiesta di offerta e confronta le risposte nella scorecard di valutazione dei fornitori. Offerte calcolate sulle stesse storie si confrontano molto meglio di stime fatte su un brief vago.

Domande frequenti

Strumenti correlati