“Aggiungere un filtro per data nella tabella ordini.” Questa frase, scritta su una card del backlog, sembra una user story. Non lo è. È un compito tecnico travestito. Manca la persona che ne ha bisogno e manca il motivo per cui lo vuole. Riscritta come si deve diventa: “Come responsabile magazzino, voglio filtrare gli ordini per data, così da preparare le spedizioni del giorno senza scorrere centinaia di righe.” La differenza non è cosmetica. Nella seconda versione il team capisce chi serve, cosa fa quella persona e perché. E può discutere se il filtro per data sia davvero la soluzione migliore, oppure se basti un ordinamento.

Questa è la promessa della user story: spostare la conversazione dal “cosa costruire” al “per chi e perché”. In questo articolo vediamo come scriverne di buone, con esempi concreti, i criteri INVEST e gli errori che vedo ripetersi quasi ogni settimana.

Cos’è una user story e perché si usa

Una user story è una descrizione breve di una funzionalità raccontata dal punto di vista di chi la userà. Non è una specifica completa. È un promemoria per una conversazione: dice abbastanza da far capire il valore, ma lascia i dettagli alla discussione tra product manager, sviluppatori e designer.

Il senso profondo è cambiare il baricentro del lavoro. Quando un backlog è pieno di voci come “implementare endpoint API” o “aggiungere campo al form”, il team costruisce cose senza sapere a chi servono. La user story obbliga a partire dal bisogno: chi è la persona, cosa sta cercando di fare, quale problema risolve. Il “cosa” diventa una conseguenza, non il punto di partenza.

Il formato classico

La struttura più diffusa, introdotta in ambito agile, è semplice:

Come [ruolo], voglio [azione], così da [beneficio].

Tre pezzi, ognuno con un compito preciso. Il ruolo dice chi parla: non “l’utente” generico, ma un profilo riconoscibile. L’azione è cosa quella persona vuole fare. Il beneficio è il perché, ed è la parte che quasi tutti dimenticano, anche se è la più importante.

Qualche esempio scritto bene:

• Come cliente abituale, voglio salvare il mio metodo di pagamento, così da concludere gli acquisti futuri in pochi secondi.
• Come amministratore, voglio disattivare un account senza cancellarlo, così da bloccare l'accesso mantenendo lo storico delle attività.
• Come neoassunto, voglio una checklist di onboarding nella dashboard, così da capire cosa fare nei primi giorni senza chiedere a un collega.

Notate che il beneficio non è mai ovvio. “Così da concludere gli acquisti in pochi secondi” è diverso da “così da risparmiare tempo”: specifica il valore in modo che si possa verificare se la soluzione lo raggiunge.

Cosa rende buona una user story: i criteri INVEST

Bill Wake ha proposto un acronimo utile per controllare la qualità di una storia: INVEST.

• Independent (indipendente): si può sviluppare e rilasciare da sola, senza dipendere da un’altra storia.
• Negotiable (negoziabile): non è un contratto rigido, è un punto di partenza per discutere la soluzione.
• Valuable (di valore): porta un beneficio reale a chi la userà, non solo al team tecnico.
• Estimable (stimabile): il team riesce a stimare quanto lavoro serve. Se non ci riesce, di solito manca chiarezza.
• Small (piccola): sta dentro uno sprint, idealmente pochi giorni di lavoro.
• Testable (testabile): si può verificare in modo oggettivo se è stata completata.

INVEST non è un esame da superare riga per riga. È una checklist mentale. Se una storia non è stimabile, probabilmente è troppo vaga. Se non è piccola, va spezzata. Se non è di valore, forse non andrebbe nel backlog.

I criteri di accettazione

La storia dice il “cosa” e il “perché”. I criteri di accettazione dicono quando è davvero finita. Sono condizioni concrete, scritte in anticipo, che permettono a chiunque di verificare il risultato. Un formato comune è “Dato… quando… allora…”.

Storia: Come cliente, voglio recuperare la password dimenticata, così da rientrare nel mio account senza contattare l’assistenza.

Criteri di accettazione:
– Dato un indirizzo email registrato, quando richiedo il recupero, allora ricevo un’email con un link valido per 24 ore.
– Dato un indirizzo non registrato, quando richiedo il recupero, allora vedo un messaggio neutro che non rivela se l’email esiste.
– Dato un link scaduto, quando lo apro, allora posso richiederne uno nuovo.

Senza criteri di accettazione, “finito” diventa un’opinione. Con loro, è un fatto.

User story, epic e task: che differenza c’è

Questi tre termini si confondono spesso, ma indicano livelli diversi di granularità.

• Un’epic è un grande obiettivo che non sta in uno sprint. Esempio: “Permettere ai clienti di gestire il proprio profilo.” Contiene molte storie.
• Una user story è una singola fetta di valore, dal punto di vista dell’utente. Esempio: “Come cliente, voglio cambiare l’indirizzo di fatturazione, così da ricevere fatture corrette.”
• Un task è un’attività tecnica necessaria a realizzare la storia, dal punto di vista del team. Esempio: “Aggiungere la validazione del CAP” oppure “Scrivere i test per il form indirizzo.”

Regola pratica: la storia descrive un valore per chi usa il prodotto, il task descrive un pezzo di lavoro per chi lo costruisce. Se quello che hai scritto non interessa a nessun utente, probabilmente è un task, non una storia.

Gli errori più comuni

Dopo aver letto migliaia di card, gli errori che ricorrono sono sempre gli stessi.

Storie troppo grandi. “Come utente, voglio gestire i miei dati” non è una storia, è un’epic mascherata. Non è stimabile né piccola. Va spezzata in fette concrete: modificare l’email, scaricare i dati, cancellare l’account.

Scritte come specifiche tecniche. “Come sistema, voglio una coda Redis per processare le notifiche.” Il sistema non è un utente. Questa è una decisione architetturale, legittima, ma non va nel formato user story: confonde il valore con l’implementazione.

Senza il “perché”. Tagliare il “così da…” è la pigrizia più diffusa. “Come utente, voglio esportare in PDF.” E poi? Senza il beneficio, il team non può proporre alternative né capire la priorità. Il perché è la parte negoziabile più preziosa.

Ruolo generico. Se ogni storia inizia con “Come utente”, tutte le persone diventano la stessa persona. Un amministratore, un cliente occasionale e un power user hanno bisogni diversi. Nominarli cambia le scelte di design.

Domande frequenti

La user story va sempre scritta nel formato “Come…, voglio…, così da…”?

No, è una convenzione utile ma non un obbligo. Alcuni team usano il formato “Job Story” (“Quando… voglio… così da…”) o frasi libere. L’importante è che restino chiari i tre elementi: chi, cosa e perché. Il formato serve a non dimenticarli, non a riempire una casella.

Quanto deve essere dettagliata una user story?

Quel tanto che basta per avviare una conversazione, non di più. Una storia troppo dettagliata diventa una specifica rigida e perde la qualità “negoziabile” di INVEST. I dettagli emergono nella discussione tra PM e team e si fissano nei criteri di accettazione, non nel testo della storia.

Chi scrive le user story, il product manager o il team?

Spesso le bozza il product manager, perché presidia il valore e la voce degli utenti, ma le storie migliori nascono in modo collaborativo. Il team contribuisce con vincoli tecnici e idee alternative. La storia è di tutti: il PM ne è responsabile, non l’unico autore.

Scrivere user story sembra banale finché non lo si fa sul serio. La parte difficile non è la sintassi, è la disciplina di partire sempre dalla persona e dal suo bisogno. Quando una storia è piccola, di valore e testabile, il lavoro a valle scorre. Quando è vaga, ogni problema si scarica più avanti, in fase di sviluppo o, peggio, dopo il rilascio. Vale la pena fermarsi qualche minuto in più a scriverla bene.