Un aspetto molto importante nella gestione dei requisiti tramite storie utente è la creazione delle storie, in cui le storie vengono identificate e poi ciascuna scritta su una scheda. Una buona storia è caratterizzata da sei proprietà riconosciute dall'acronimo INVEST:
La dimensione delle storie di una eventuale suddivisione in storie più piccole è già stata discussa in Suddividere e combinare le storie. A volte può essere utile scrivere delle storie grandi, come promemoria per funzionalità di sistema la cui investigazione può essere rimandata a iterazioni successive.
Il team deve essere in grado di stimare (approssimativamente) il lavoro richiesto per implementare ciascuna storia utente. Per esempio, come numero di giorni di lavoro di una coppia di sviluppatori. Se sono state identificate delle storie che non sono stimabili, allora vanno riscritte in modo tale da esserlo.
Per quanto possibile è meglio evitare dipendenze fra le storie, poiché possono dar luogo a problemi di stima e nell'assegnazione delle priorità.
Nel caso in cui un team non abbia mai gestito lo sviluppo di un sistema di pagamento con carta di credito:
| Storie non indipendenti | Storie indipendenti |
|---|---|
| Un cliente può pagare per una vendita con MasterCard | Un cliente può pagare per una vendita con il tipo di carta numero 1 |
| Un cliente può pagare per una vendita con Visa | Un cliente può pagare per una vendita con il tipo di carta numero 2 |
Nelle storie indipendenti si noti che il tipo di carta non è specificato ed è indipendente dal tipo specifico (Visa, Mastercard).
Molte storie sono di valore per gli utenti del sistema. Tuttavia, sono rilevanti anche storie di valore per altre parti interessate, e in particolare per chi acquisterà il prodotto software.
Vanno evitate storie che hanno valore solo per gli sviluppatori. Se tali storie rappresentano requisiti importanti è preferibile riscriverle sotto forma di storie che abbiano valore per gli utenti o gli acquirenti.
| Storie di valore solo per gli sviluppatori | Storie di valore per utenti o acquirenti |
|---|---|
| Tutti i dati sono presentati agli utenti mediante pagine HTML e fogli di stile CSS | Tutti i dati sono presentati agli utenti con uno stile uniforme e che può essere personalizzato facilmente |
| L'applicazione deve utilizzare la base di dati dei prodotti già esistente | L'applicazione deve utilizzare la base di dati dei prodotti già esistente, anziché crearne una nuova, in modo da non avere una base di dati in più da gestire. |
La prima di queste storie ha valore per l'utente, probabilmente.
La seconda invece, per l'acquirente, e certamente per l'amministratore delle basi di dati.
Le storie sono brevi descrizioni di requisiti, i cui dettagli vanno discussi e negoziati in una successiva conversazione tra team di sviluppo e utenti/clienti. Non sono contratti scritti o requisiti espressi in modo dettagliato. La sfida è imparare a includere in ciascuna storia solo quanto basta.
Se nel momento in cui viene creata una storia sono noti alcuni dettagli importanti, questi possono essere scritti sulla scheda come annotazioni. Per esempio:
Tuttavia, bisogna evitare di aggiungere troppi dettagli
Quando una storia rappresenta una funzionalità, ovvero un requisito funzionale, i test di accettazione per la storia possono essere di solito identificati durante la conversione e scritti, in modo informale, sul retro della scheda per la storia. Per quanto possibile, questi test di accettazione andranno poi implementati come test automatizzati, utilizzando strumenti opportuni.
| Storia non verificabile | Storia verificabile |
|---|---|
| Non bisogna mai aspettare troppo per la risposta a un'autorizzazione di pagamento con carta di credito | Risposta a un'autorizzazione di pagamento con carta di credito entro 30 secondi nel 90% dei casi |
La storia a sinistra non è verificabile.
Formato: Come "tipo utente", voglio "obiettivo" in modo che "motivazione"
Esempi:
La storia viene scritta dal punto di vista dell'utente e in forma attiva e in prima persona
Ecco alcuni ulteriori guida per la scrittura di storie utente:
Ecco un esempio di storie utente per il gioco del Monopoly.