User Stories

Le user stories sono un modo di esprimere i requisiti dal punto di vista dell'utente, in forma breve e conversazionale. Sono nate in XP (eXtreme Programming, Kent Beck) e sono oggi lo standard de facto nei team Agile/Scrum.

Una user story non è una specifica tecnica. È un promemoria di una conversazione da fare con il team.

Il formato classico

Connextra format (Connextra Ltd., 2001), il più diffuso:

Come [persona / ruolo]
voglio [azione / funzionalità]
così che [valore / beneficio]

Esempio

Come freelance in regime forfettario, voglio importare automaticamente le fatture emesse dal mio gestionale così che non debba inserirle a mano nel sistema di rendicontazione.

Le 3 parti spiegate

La regola d'oro: outcome, non solution

Nella prima colonna, il team non può proporre alternative. Nella seconda sì.

Le 3 C (Ron Jeffries)

Una user story ben fatta segue le 3 C:

⚠ Se la story viene scritta dal PO e lanciata al team senza conversazione, sei fuori dallo spirito Agile. Stai facendo waterfall mascherato.

INVEST: criteri di qualità

Acronimo di Bill Wake (2003). Una buona story è:

Vedi anche Task → INVEST, dove gli stessi criteri si applicano ai task generici.

Acceptance Criteria

Sono le condizioni di accettazione che rendono la story "fatta bene". Senza, la story è un'opinione.

Formato 1: Lista puntata (semplice)

Story: Come freelance, voglio recuperare la password dimenticata, così che possa riaccedere senza chiedere supporto.

Acceptance Criteria:
- Esiste un link "password dimenticata" nella pagina di login
- Inserendo un'email valida, l'utente riceve un'email di reset entro 60 secondi
- Il link nell'email scade dopo 24 ore
- Inserendo email non registrata, il messaggio è generico (per security)
- La nuova password rispetta i requisiti di sicurezza (min 8 char, ecc.)
- Dopo il reset, l'utente viene loggato automaticamente

✓ Pro: semplice, leggibile. ✕ Contro: meno strutturato per testing automatico.

Formato 2: Given-When-Then (BDD / Gherkin)

Stile Behavior-Driven Development, più strutturato.

Scenario: Recupero password con email valida
  Given un utente registrato con email "marco@example.com"
  When  richiede il recupero password
  Then  riceve un'email di reset entro 60 secondi
  And   il link nell'email è valido per 24 ore
 
Scenario: Recupero password con email non registrata
  Given un'email "fake@example.com" non presente nel database
  When  viene richiesto il recupero
  Then  il messaggio mostrato è generico e non rivela l'esistenza
  And   nessuna email viene inviata

✓ Pro: chiaro, traducibile in test automatizzati (Cucumber, SpecFlow). ✕ Contro: verboso, può sembrare burocratico in story semplici.

Acceptance Criteria vs Definition of Done

Spesso confusi. Vedi anche Definition of Done:

Una story è Done quando soddisfa sia i suoi acceptance criteria sia la DoD del team.

La gerarchia: Theme → Initiative → Epic → Story → Task

User stories vivono in una gerarchia:

Epic è una story troppo grande per uno sprint: va spezzata.

Story Splitting: l'arte di spezzare

La domanda più frequente in Scrum: "questa story è troppo grande, come la spezzo senza perdere il valore?"

Pattern di splitting (Richard Lawrence)

1. Workflow Steps

Spezza per passi del flusso.

• Story: "Come admin, voglio gestire i clienti"
• Split: Crea cliente / Modifica cliente / Elimina cliente / Esporta lista

2. Business Rule Variations

Spezza per regole di business.

• Story: "Come utente, voglio fare un pagamento"
• Split: Pagamento standard / Pagamento con voucher / Pagamento con coupon

3. Happy Path / Edge Cases

Prima il caso felice, poi i casi limite.

• Story: "Login"
• Split: Login con credenziali valide → Gestione errori → Account bloccato → 2FA

4. Interface Variations

Spezza per canale/dispositivo.

• Story: "Visualizzazione dashboard"
• Split: Dashboard desktop → Dashboard mobile → Dashboard print

5. Data Variations

Spezza per tipo di dato/contesto.

• Story: "Filtraggio risultati"
• Split: Filtro per testo / Filtro per data / Filtro combinato

6. CRUD Operations

Crea, Leggi, Aggiorna, Cancella separate.

7. Defer Performance / Polish

Versione funzionante prima, polish dopo.

• v1: "Funziona, sufficientemente veloce"
• v2: "Ottimizzato"

8. Major Effort

Spezza per la parte tecnica più complessa.

• Story: "Integrazione SdI"
• Split: Setup credenziali / Invio singola fattura / Gestione errori / Riconciliazione

La regola SPIDR (alternativa)

Acronimo di Mike Cohn: Spikes, Paths, Interfaces, Data, Rules.

Lo Story Map (Jeff Patton)

Una story map è una visualizzazione bidimensionale delle user story:

• Asse orizzontale: il viaggio dell'utente (la "spina dorsale")
• Asse verticale: livelli di priorità / release

✓ Pro: aiuta a non dimenticare attività dell'utente, prioritizza per release, conversazione visiva.

Strumenti per gestire le user story

Anti-pattern

• ✕ "Come utente, voglio..." → "utente" è chiunque, non dice nulla. Usa la persona specifica.
• ✕ Story-task confusion: "Come utente voglio l'endpoint REST" → è un task, non una story
• ✕ Specifica tecnica travestita da story: "Come sistema, voglio scrivere in DB..." → il "sistema" non è un utente
• ✕ Story senza "così che": nessun valore esplicito → diventa wishlist
• ✕ Story scritte dal PO in solitaria: viola la 2a C (Conversation)
• ✕ Story congelate: si scrivono e si lanciano. La 2a C è continua.
• ✕ Story enormi che durano 2 sprint: viola la S (Small) di INVEST
• ✕ Story senza acceptance criteria: la "Confirmation" manca, "Done" diventa opinione
• ✕ Acceptance criteria = task list: confonde "cosa fa" con "come è fatto"
• ✕ Troppe story aperte: backlog di 800 voci diventa un cimitero, non un piano

Esempi di user story ben fatte

B2B SaaS

Come HR Manager di una PMI, voglio inserire i nuovi dipendenti con un import CSV, così che possa onboardare 50 persone senza inserirle a una a una.

E-commerce

Come cliente abituale, voglio riordinare un mio precedente acquisto in 2 click, così che non debba cercare i prodotti uno a uno.

Healthcare

Come paziente con malattia cronica, voglio ricevere un promemoria della terapia 30 minuti prima dell'orario, così che non dimentichi di prendere i farmaci.

Marketplace

Come venditore artigiano, voglio vedere quanto guadagno dopo le commissioni della piattaforma, così che possa prezzare correttamente i miei prodotti.

Esempi di user story MALE FATTE (e correzione)

✕ "Come admin, voglio una pagina di gestione utenti."

✓ "Come admin, voglio attivare e disattivare gli account utente, così che possa rimuovere accessi a dipendenti che hanno lasciato l'azienda senza eliminare lo storico."

✕ "Come utente, voglio una migliore esperienza."

✓ "Come utente che usa l'app in metropolitana (rete intermittente), voglio che le mie modifiche vengano sincronizzate automaticamente al ritorno della connessione, così che non perda il lavoro fatto offline."

✕ "Come sistema, voglio scrivere log su file."

✓ Non è una user story. È un task tecnico. Va nel Sprint Backlog ma non come story (oppure si trasforma in un'esigenza utente: "Come SRE in caso di incidente, voglio i log delle ultime 24h disponibili, così che possa diagnosticare velocemente").

User story per progetti non software

I principi si applicano a qualsiasi prodotto/servizio orientato all'utente:

Marketing

Come lead in fase di valutazione, voglio ricevere case study del mio settore, così che possa convincere il mio capo della scelta.

Eventi

Come partecipante che vuole networking, voglio vedere chi altri partecipa al mio panel preferito, così che possa contattarli prima dell'evento.

HR

Come nuovo assunto al primo giorno, voglio trovare già configurato il mio computer, così che possa iniziare a lavorare senza chiedere a IT.

Workflow consigliato per scrivere story

1. Parti dalla persona o dal job to be done
2. Identifica l'outcome desiderato, non la soluzione
3. Scrivi il "così che" prima (perché → forza il pensiero sul valore)
4. Mantienila piccola: se è grande, segna come Epic e spezzala
5. Discutila col team (la C di Conversation): non lanciarla
6. Aggiungi acceptance criteria durante la conversazione, non prima
7. Stima con il team (story points o t-shirt)
8. Refinement continuo: non è scolpita nella pietra

Story Slicing: il test "INVEST" applicato

Quando proponi una story al team, fagli verificare:

• È chi è l'utente specifico? (non "come utente")
• Il valore (così che) è esplicito e credibile?
• Sta in uno sprint?
• Ha almeno 3 acceptance criteria?
• Si può iniziare senza dipendere da story aperte?
• Sono chiare le ipotesi e le esclusioni?
• Il team riesce a stimarla con confidenza ≥ medium?

Collegamenti

• Task — granularità sotto la story
• Personas — il "chi" della story
• Definition of Done / Ready — DoR garantisce che le story siano "ready", DoD che siano "done"
• Scrum — le story sono gli item del Product Backlog
• Kanban — le story sono le card della board
• Scope — l'insieme delle story definisce lo scope
• MVP — l'MVP è un insieme minimale di story "Must have"
• Roadmap — la roadmap aggrega epic, le epic aggregano story

Per approfondire

• User Stories Applied — Mike Cohn (il classico)
• User Story Mapping — Jeff Patton (story map)
• Fifty Quick Ideas to Improve Your User Stories — Gojko Adzic
• Specification by Example — Gojko Adzic (acceptance criteria avanzati)