Storie utente con esempi e un modello

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 user story è una descrizione generale e informale di una funzionalità del software scritta dal punto di vista dell'utente finale o del cliente. 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 sono necessariamente utenti finali esterni nel senso tradizionale del termine. Possono anche essere clienti interni o colleghi all'interno 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 user story che aiuta i team Scrum a migliorare le stime e la pianificazione dello sprint e a ottenere così previsioni più accurate e 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 user story sono inoltre gli elementi costitutivi di framework Agile più ampi, come epic e iniziative. Gli epic sono ticket di grandi dimensioni suddivisi in una serie di story, mentre più epic costituiscono un'iniziativa.

Queste strutture più ampie assicurano che il lavoro quotidiano del team di sviluppo (sulle story) contribuisca agli obiettivi dell'organizzazione integrati in epic e iniziative. Puoi scoprire di più su epic e iniziative qui!

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 l'attenzione 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ò dedicarsi alla risoluzione dei problemi degli utenti reali. 

• Le story agevolano la collaborazione. Con un obiettivo finale ben definito, il team può collaborare per decidere come assistere al meglio l'utente e raggiungere tale obiettivo. 

• Le story portano a 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 storie utente in Jira Software

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 il team definisce le specifiche di ogni story, deve assicurarsi di suddividere in più parti le story che superano il limite di completamento previsto.

Quando scrivi user story, 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 user story, 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.