Le storie degli utenti sono una breve descrizione di un prodotto scritta dal punto di vista dell'utente finale. Possono includere alcuni dei seguenti elementi: caratteristiche, funzionalità, correzioni di bug, richieste di miglioramento, configurazione dell'infrastruttura o documentazione tecnica. Lo scopo di una user story è quello di spiegare come una funzionalità fornirà valore al cliente.
Uno degli elementi chiave dell'approccio Agile è mettere le persone al primo posto, e una user story mette l'utente finale al centro della pianificazione e dell'esecuzione di un prodotto. Queste storie sono informali e non tecniche per fornire un contesto di vita reale al team di sviluppo. La lettura delle storie dell'utente dovrebbe consentire al team di comprendere meglio il prodotto che sta costruendo e il valore che crea per l'utente.
In generale, le storie degli utenti aiutano il team a mantenere l'attenzione sull'utente nel lavoro quotidiano, che a sua volta stimola la collaborazione, la creatività e un prodotto complessivamente migliore.
Chi è responsabile delle storie utente?
All'interno del team Agile non c'è una sola persona o un solo ruolo responsabile delle storie utente. Infatti, tutti coloro che partecipano al progetto possono scrivere storie utente, dai membri del team fino agli stakeholder. Tuttavia, molte storie vengono scritte durante un affinamento del backlog o pianificazione dello sprint riunione del team di sviluppo e dell'Product Owner.
Vale anche la pena di notare che chi scrive la storia utente è molto meno importante di chi è coinvolto nella discussione della stessa.
Come scrivere le storie utente
È utile considerare quanto segue quando si scrivono le storie utente:
L'Definition of Done:
È importante avere una chiara comprensione di ciò che è necessario perché la storia utente sia fatta. La storia può essere considerata "fatta" quando l'utente finale è in grado di completare il compito delineato (spesso indicato come Criteri di soddisfazione) e quando soddisfa gli standard concordati (Definition of Done).
Feedback:
Collaborare con gli utenti per cogliere il problema o l'esigenza nelle loro parole. Non ha alcun valore indovinare ciò che vogliono.
Utilizzare passi ordinati:
Scrivete una storia per ogni fase del processo o dell'obiettivo più ampio.
Personaggi utente:
Una comprensione condivisa tra il team di chi è l'utente finale e le sue esigenze specifiche.
Flusso:
Se una storia può richiedere più tempo della durata di una Sprint, deve essere suddivisa in storie più piccole o deve essere considerata una "Epic" a sé stante. La stima delle storie utente è utile per valutare se le storie devono essere ulteriormente suddivise per garantire un flusso di lavoro omogeneo.
Una volta definite chiaramente le storie utente, è importante assicurarsi che siano visibili a tutto il team.
Modelli ed esempi di storie utente
Le storie degli utenti sono spesso scritte su schede, note adesive o, se i team optano per una versione digitale, su software online. Un modello spesso utilizzato è il seguente:
Come [tipo di utente], voglio [qualche funzione] in modo che [qualche valore].
Scomponiamo ulteriormente la questione:
- [Tipo di utente]: Si tratta esattamente di chi utilizza il prodotto e della sua persona. Il team deve avere una comprensione condivisa di chi sono e dei loro requisiti.
- [Qualche obiettivo]: Qui si descrive l'intento piuttosto che una caratteristica specifica che si vuole utilizzare.
- [Qualche motivo]: Infine, questo è il motivo per cui si sta cercando di ottenere questo risultato. Cioè, qual è il beneficio generale che si sta cercando di ottenere? Qual è il problema più grande da risolvere?
Ad esempio, le storie dell'utente in pratica potrebbero avere questo aspetto:
- In qualità di [utente], desidero [specificare le cartelle di cui eseguire il backup] in modo che [non venga eseguito il backup della mia unità con cartelle non necessarie].
- Come [utente], voglio [organizzare il mio spazio di lavoro virtuale] in modo da [sentirmi più padrone del mio lavoro].
- Come [manager], voglio [essere in grado di capire i progressi della squadra] in modo da [poter riferire su successi e fallimenti con facilità].
Non è necessario che seguano sempre questa struttura, ma può essere utile per definire i criteri di soddisfazione e la definizione di "Fatto".
[Per saperne di più sull'Definition of Done, consultare le altre risorse qui].
Perché creare storie utente?
Abbiamo esplorato cosa sono le storie utente e come crearle, ma è anche importante capire perché la creazione di storie utente fornisce un valore reale ai team. A volte, per i team di sviluppo che non conoscono Agile, le storie utente possono sembrare un passo in più e non necessario. Tuttavia, le storie forniscono al team un contesto utile e associano i compiti al valore che essi apportano.
Alcuni dei principali vantaggi delle storie utente includono:
- Le storie favoriscono la collaborazione. Avere un obiettivo finale chiaramente definito può consentire al team di lavorare insieme sul modo migliore per servire l'utente finale e raggiungere l'obiettivo.
- Le storie aiutano a definire i ruoli. Grazie alla natura concisa e focalizzata sull'utente delle storie, può essere più facile separare chi si occupa di cosa e definire i ruoli.
- Le storie creano slancio. Essendo piccole unità di lavoro, il team può festeggiare regolarmente le vittorie, il che aiuta a creare e mantenere lo slancio.
- Le storie incoraggiano il pensiero creativo. Le storie aiutano il team a pensare in modo creativo al modo migliore per risolvere un obiettivo finale.
Sintesi
In sintesi, è chiaro che le storie degli utenti offrono alcuni vantaggi considerevoli. Mettere l'utente finale al centro del lavoro e della conversazione crea valore, aiutando i team a costruire un prodotto di successo e motivandoli a farlo lungo il percorso. Per i team che utilizzano l'Agile è quindi importante conoscere le storie e utilizzarle in modo efficace.
