Storie utente con esempi e un modello

Riepilogo: una storia utente è una spiegazione informale e generale di una funzione del software scritta dalla prospettiva dell'utente finale. Il suo scopo consiste nello spiegare in che modo la funzione del software è in grado di fornire valore al cliente.

Si potrebbe essere tentati dal pensare che le storie utente siano, in poche parole, requisiti di sistema del software. Ma non lo sono.

Un componente chiave dello sviluppo di software Agile è mettere le persone al primo posto e una storia utente mette gli utenti finali al centro della conversazione. Queste story utilizzano un linguaggio non tecnico per fornire contesto al team di sviluppo e al loro lavoro. Dopo aver letto una storia utente, il team è cosciente di ciò che sta compilando, perché lo sta compilando e quale valore è in grado di fornire con il suo lavoro.

Le storie utente sono uno dei componenti principali di un programma Agile. Contribuiscono a fornire un framework incentrato sull'utente per il lavoro quotidiano, in grado di favorire la collaborazione, la creatività e rilasciare un prodotto nel complesso migliore.

Una storia utente è la più piccola unità di lavoro di un framework Agile. È un obiettivo finale, non una funzione, espresso dal punto di vista dell'utente del software.

Una storia utente è una spiegazione generale e informale, scritta dal punto di vista di un utente finale o di un cliente, che riguarda una funzione del software.

Lo scopo di una storia utente è articolare il modo in cui un lavoro restituirà un valore particolare al cliente. Tieni presente che i "clienti" non devono per forza essere utenti finali esterni nel senso tradizionale, possono essere anche clienti interni o colleghi della tua organizzazione che dipendono dal tuo team.

Le storie utente sono nello specifico frasi scritte in un linguaggio semplice e che delineano il risultato desiderato, senza entrare nei dettagli. I requisiti vengono aggiunti successivamente, una volta concordati dal team.

Le story si adattano perfettamente a framework Agile come Scrum e Kanban. In Scrum, le storie utente vengono aggiunte agli sprint e "consumate" per tutta la durata dello sprint. I team Kanban eseguono un pull delle storie utente nel loro backlog e le eseguono nel loro flusso di lavoro. È questo lavoro sulle storie utente che aiuta i team Scrum a migliorare le stime e la pianificazione dello sprint, portando a previsioni più accurate e a una maggiore agilità. Grazie alle story, i team Kanban imparano a gestire il lavoro in corso (WIP) e possono perfezionare ulteriormente i loro flussi di lavoro.

Le storie utenti sono gli elementi costitutivi anche di framework Agile più ampi come epic e iniziative. Gli epic sono elementi di lavoro di grandi dimensioni suddivisi in una serie di story e più epic costituiscono un'iniziativa. Queste strutture più ampie assicurano che il lavoro quotidiano del team di sviluppo (sugli archivi) contribuisca agli obiettivi dell'organizzazione integrati in epic e iniziative.

Scopri di più su epic e iniziative

Per i team di sviluppo che usano Agile da poco, le storie utente a volte sembrano superflue. Perché non limitarsi a suddividere il progetto generale (l'epic) in una serie di fasi e andare avanti con il lavoro? Tuttavia, le story danno al team un contesto importante e associano i task al valore da loro apportato.

Le storie utente offrono una serie di vantaggi chiave:

• Le story mantengono il focus sull'utente. Con un elenco delle cose da fare, il team resta concentrato sui task da svolgere, ma con una raccolta di story, lo stesso team può mantenere la concentrazione sulla risoluzione dei problemi per gli utenti reali.
  
• Le story agevolano la collaborazione. Con un obiettivo finale ben definito, il team può collaborare per decidere il modo migliore per assistere l'utente e raggiungere tale obiettivo.
  
• Le story portano all'ideazione di soluzioni creative. Le story incoraggiano il team a pensare in modo critico e creativo su come risolvere al meglio i problemi per raggiungere l'obiettivo finale.
  
• Le story creano slancio. Con ogni story, il team di sviluppo si diverte misurandosi con piccole sfide e piccole vittorie, rinnovando così lo slancio.

Scopri come funzionano le user story in Jira

Una volta che una story è stata scritta, è il momento di integrarla nel flusso di lavoro. Generalmente una story viene scritta dall'owner di prodotto, dal product manager o dal program manager e viene quindi inviata per la revisione.

Durante una riunione sulla pianificazione dello sprint o dell'iterazione, il team decide quali story affronterà quello sprint particolare. I team passano poi a discutere dei requisiti e delle funzionalità richiesti da ogni storia utente. Si tratta di un'opportunità per approfondire l'aspetto tecnico e creativo dell'implementazione della story da parte del team. Una volta concordati, questi requisiti vengono aggiunti alla story.

Durante la riunione, viene inoltre assegnato alle story un punteggio in base alla loro complessità o al tempo di completamento. I team usano le taglie delle magliette, la sequenza di Fibonacci o il planning poker per fare stime adeguate. Una story deve avere delle dimensioni che ne consentano il completamento nell'arco di uno sprint. Quindi, quando definisce le specifiche di ogni story, il team si assicura di suddividere in più parti le story che supereranno l'orizzonte di completamento stabilito.

Quando scrivi storie utente, tieni in considerazione quanto segue:

• Definizione di "lavoro completato": la story è generalmente "completata" quando l'utente può completare il task descritto, ma assicurati di definire bene tale stato.
  
• Definisci sottotask o task: decidi quali passaggi specifici devono essere completati e chi è responsabile di ciascuno di essi.
  
• Utenti tipo: per chi? Se ci sono più utenti finali, prendi in considerazione la possibilità di creare più story.
  
• Passaggi ordinati: scrivi una story per ogni passaggio di un processo più ampio.
  
• Ascolta i feedback: parla con gli utenti e cerca di comprendere appieno il loro problema o le loro necessità utilizzando le loro parole. Non c'è bisogno di indovinare le story quando puoi sentirle direttamente dai clienti.
  
• Tempo: il tempo è un argomento delicato. Molti team di sviluppo evitano del tutto di parlare del tempo, affidandosi invece ai framework di stima. Dal momento che le story dovrebbero essere completabili in uno sprint, quelle che potrebbero dover essere completate in settimane o mesi devono essere suddivise in story più piccole o considerate per un proprio epic.
  

Una volta definite chiaramente le storie utente, assicurati che siano visibili per l'intero team.

Le storie utente sono spesso espresse tramite una frase semplice, strutturata come segue:

"Come [utente tipo], [voglio], [in modo da]."

Analizziamo questa frase:

• "Come [utente tipo]": per chi stiamo compilando questo rilascio? Non dobbiamo considerare soltanto il titolo professionale, ma anche l'utente tipo. Max. Tutto il nostro team deve sapere chi sia Max. Abbiamo già parlato con tanti altri Max in passato o almeno è questa la speranza. Sappiamo come lavora quella persona e conosciamo il suo modo di fare e pensare. Proviamo empatia per Max.
• "Voglio": qui stiamo descrivendo l'intento dell'utente, non le funzioni che utilizza. Cosa sta effettivamente cercando di ottenere? Questa affermazione dovrebbe essere priva di implementazione: se descrivi una parte qualsiasi dell'interfaccia utente e non l'obiettivo dell'utente, non stai centrando il punto.
• "In modo da": in che modo il suo desiderio immediato di fare qualcosa si inserisce nella sua situazione generale? Qual è il vantaggio complessivo che sta cercando di ottenere? Qual è il problema più importante da risolvere?

Ad esempio, le storie utente potrebbero avere il seguente aspetto:

• Come Max, voglio invitare i miei amici, in modo da poter utilizzare questo servizio insieme.
• Come Sascha, voglio organizzare il mio lavoro, in modo da sentire di avere il controllo.
• Come manager, voglio essere in grado di comprendere l'avanzamento dei miei colleghi, in modo da poter creare migliori report sui successi e sui fallimenti.

Questa struttura non è obbligatoria, ma è utile per poter considerare il lavoro completato. Quando quell'utente tipo riesce ad acquisire il valore desiderato, allora la story è completa. Incoraggiamo i team a definire una propria struttura e a rispettarla.

Le storie utente descrivono il perché e il cosa dietro il lavoro quotidiano dei membri del team di sviluppo e sono spesso espresse con la struttura utente tipo + necessità + scopo. Comprendere il loro ruolo come fonte di riferimento su ciò su cui il team sta lavorando, ma anche sul perché ci sta lavorando, è la chiave per un processo senza intoppi.

Inizia valutando il progetto successivo o quello più urgente o di maggiori dimensioni (ad esempio un epic). Suddividilo in storie utente più piccole e collabora con il team di sviluppo per il perfezionamento. Una volta che le story sono state presentate in una posizione accessibile dall'intero team, puoi metterti al lavoro.