Guida Agile · Pratiche Agile
User story: come scriverle, con modelli ed esempi
Una user story è una breve descrizione, in linguaggio semplice, di qualcosa di cui un utente ha bisogno, scritta dal suo punto di vista. Indica chi la desidera, che cosa desidera e perché, e funge da segnaposto per una conversazione sui dettagli anziché da specifica completa.
Punti chiave
- Una user story indica chi ha bisogno di qualcosa, di che cosa ha bisogno e perché.
- I criteri di accettazione rendono testabile ogni story; la Definition of Done si applica a tutte le story.
- Usate INVEST per verificarne la qualità e suddividete le story che non rientrano in uno sprint.
- Le story sono un punto di partenza per la conversazione, non una specifica completa.
Il modello di user story
Il formato più comune è: In qualità di [tipo di utente], voglio [un obiettivo] in modo da [un beneficio].
- Chi: un utente o un ruolo specifico, non "il sistema".
- Cosa: l'obiettivo o la capacità di cui ha bisogno, non la soluzione tecnica.
- Perché: il beneficio, che aiuta il team a trovare il modo più semplice per realizzarla.
Molti team descrivono una story con le tre C: la scheda (la breve story scritta), la conversazione (la discussione che ne definisce i dettagli) e la conferma (i criteri di accettazione che dimostrano che è completata).
Criteri di accettazione
I criteri di accettazione sono le condizioni che una story deve soddisfare per essere accettata. Rendono la story testabile e riducono i malintesi. Due stili comuni:
- Checklist: "La prenotazione mostra orario e sede del corso"; "Il socio riceve un'email di conferma".
- Given-When-Then: "Dato che un corso ha posti liberi, quando un socio tocca Prenota, allora un posto viene riservato e il numero di posti liberi diminuisce di uno."
La checklist INVEST
| Lettera | Significato | Domanda da porsi |
|---|---|---|
| I | Indipendente | Può essere consegnata senza attendere un'altra story? |
| N | Negoziabile | I dettagli sono aperti alla discussione anziché fissati? |
| V | Di valore | Offre valore a un utente o all'azienda? |
| E | Stimabile | Il team la comprende abbastanza bene da poterla stimare? |
| S | Piccola | Può essere completata entro uno sprint? |
| T | Testabile | Ci sono criteri di accettazione chiari? |
Come scrivere una user story, passo dopo passo
- Identificate l'utente e il suo obiettivo, idealmente sulla base di ricerche o feedback reali.
- Scrivete la story usando il modello, limitandola a una o due frasi.
- Aggiungete da tre a sei criteri di accettazione.
- Discutetela con il team durante il backlog refinement e adeguatela.
- Verificatela con INVEST; suddividetela se è troppo grande.
- Stimatela, ad esempio con gli story point.
- Ordinatela nel product backlog in base a valore, rischio e dipendenze.
Esempi: deboli e migliorati
| Story debole | Story migliorata |
|---|---|
| In qualità di utente, voglio una tabella del database per le prenotazioni. | In qualità di socio, voglio prenotare un corso in modo che il mio posto sia riservato. |
| In qualità di sistema, voglio inviare email. | In qualità di socio, voglio un'email di conferma della prenotazione in modo da avere traccia del mio corso. |
| In qualità di utente, voglio che il sito sia veloce. | In qualità di utente mobile, voglio che l'orario si carichi in meno di due secondi in modo da poter prenotare in movimento. |
| In qualità di amministratore, voglio un modulo di report con 15 report. | In qualità di responsabile della palestra, voglio vedere le presenze settimanali per corso in modo da poter adeguare l'orario. |
Esempio completo: In qualità di socio, voglio iscrivermi a una lista d'attesa quando un corso è pieno in modo da ottenere un posto se qualcuno disdice. Criteri di accettazione: il pulsante Iscriviti alla lista d'attesa compare solo quando un corso è pieno; il socio vede la propria posizione; quando si libera un posto, viene offerto via email alla prima persona, che ha due ore per accettare.
Errori comuni
- Scrivere attività tecniche camuffate da story.
- Story così grandi da estendersi su più sprint; trattatele come epic e suddividetele.
- Nessuna clausola "in modo da", il che nasconde il bisogno reale.
- Trattare la story come un contratto invece che come l'avvio di una conversazione.
- Criteri di accettazione mancanti o vaghi, che portano a rilavorazioni.
- Scrivere ogni story secondo il modello anche quando una frase semplice sarebbe più chiara.
Modelli gratuiti per questo argomento
Domande frequenti
Che cos'è una user story in Agile?
Una breve descrizione di un bisogno dell'utente, scritta dal suo punto di vista, che il team trasforma in funzionalità funzionanti.
Qual è il formato di una user story?
In qualità di [tipo di utente], voglio [obiettivo] in modo da [beneficio].
Chi scrive le user story?
Chiunque può scriverle, ma di solito è il product owner a essere responsabile di assicurarsi che siano chiare e ordinate nel backlog.
Le user story fanno parte di Scrum?
No. La Guida Scrum parla di elementi del Product Backlog; le user story sono un modo diffuso per scriverli.
Cosa sono i criteri di accettazione nelle user story?
Condizioni specifiche e verificabili che una story deve soddisfare per essere accettata, spesso scritte come checklist o nel formato Given-When-Then.
Quanto dovrebbe essere piccola una user story?
Abbastanza piccola da essere completata entro uno sprint, e idealmente in pochi giorni.
Che cosa significa INVEST nelle user story?
Independent, Negotiable, Valuable, Estimable, Small e Testable (indipendente, negoziabile, di valore, stimabile, piccola e testabile).
Qual è la differenza tra una user story e un requisito?
Un requisito tradizionale specifica in dettaglio che cosa deve fare il sistema; una user story descrive un bisogno e invita alla conversazione per concordarne i dettagli. Vedi requisiti di progetto.
Qual è la differenza tra una user story e un'epic?
Un' epic è un grande blocco di lavoro composto da molte story; una story rientra in un singolo sprint.
Come si stimano le user story?
La maggior parte dei team usa una stima relativa, come gli story point o le taglie T-shirt, concordata insieme dal team.
Le user story si possono usare al di fuori del software?
Sì. I team di marketing e di altro tipo scrivono story come "In qualità di potenziale cliente, voglio un confronto dei prezzi in modo da poter scegliere un piano"; vedi Agile marketing.