Storia dell'utente

Che cos'è una user story?

Una user story fa parte di un framework di gestione dei progetti agile. Descrive quali caratteristiche desiderano gli utenti finali per ottimizzare la loro soddisfazione con un prodotto e ottenere il massimo valore possibile da esso.

La dichiarazione della user story si riferisce tipicamente a un obiettivo specifico e al motivo per cui una caratteristica attrae l'utente. Ad esempio, "Come visitatore del sito, voglio vedere un menu o un elenco di corsi disponibili per aiutarmi a trovare il migliore da seguire" sarebbe una user story per qualcuno che guarda un sito web per l'istruzione online.

Le user story sono sempre dal punto di vista dell'utente, anche se è il team interno a scriverle effettivamente. Sono tipicamente archiviate in software di gestione dei progetti per il team di progetto da rivedere mentre vengono sviluppati nuovi prodotti e servizi.

Tipi di user stories

Le user stories create per ciascun progetto vivranno con il product backlog per un facile riferimento mentre il prodotto viene sviluppato. I team agili possono utilizzare tre tipi di user stories.

• User stories target sono il tipo più comune. Sono formulate dal punto di vista del cliente target del prodotto per creare una dichiarazione facile da comprendere che il team può utilizzare per costruire caratteristiche attorno ai desideri e alle esigenze del cliente.
• Non-user stories sono efficaci quando le caratteristiche di un prodotto non hanno una correlazione diretta con l'utente, ma possono comunque essere utili per il team di sviluppo. In queste situazioni, una dichiarazione non-user aiuta a costruire un prodotto complessivamente migliore.
• Spikes sono brevi dichiarazioni che indicano al team che è necessaria un'ulteriore ricerca su uno o due problemi, che possono essere successivamente testati per prevenire ulteriori problemi in futuro. I problemi possono emergere basandosi su user e non-user stories che devono essere affrontati.

Elementi di base delle user stories

Le user stories differiscono a seconda del progetto e del tipo di utente. Ma la loro composizione di base dovrebbe essere simile, utilizzando i quattro elementi:

• La carta. Ogni user story dovrebbe seguire il formato "come [chi], voglio [cosa] in modo che [perché]". Chiamata la carta per aiutare a limitare lo spazio, questo elemento dovrebbe essere il più possibile a livello alto per mantenere la dichiarazione semplice.
• La conversazione. Poiché i membri del team interno sono quelli che scrivono le user stories, la parte della conversazione nello sviluppo di queste riguarda tutto il replicare argomenti che un utente target potrebbe discutere quando utilizza il prodotto. Questo dovrebbe essere un processo collaborativo tra entrambi stakeholder e sviluppatori.
• La conferma. Prima che le user stories possano informare lo sviluppo del prodotto, il team interno dovrebbe concordare sui criteri di accettazione. Non tutti gli utenti avranno suggerimenti che si trasformano in caratteristiche del prodotto.
• Il contesto. Le storie individuali sono utili per sviluppare caratteristiche, ma devono essere correlate al concetto più ampio del prodotto.

Vantaggi delle user stories

Molte user stories raccontano al team di sviluppo esigenze o desideri simili che stanno cercando da un prodotto. Gli sviluppatori possono quindi tenere conto di queste informazioni mentre lavorano. Alcuni degli altri vantaggi di interagire con le user stories includono:

• Migliorare il prodotto finale. Anche se il feedback non proviene necessariamente dall'utente finale, le user stories costringono il team interno a pensare come tale. Questo incoraggia la conversazione su ciò che un utente vuole dal prodotto.
• Lavorare con i principali stakeholder. Gli utenti saranno il pensiero principale dietro le user stories, ma altri stakeholder chiave potrebbero aver bisogno di input interni sui cambiamenti del prodotto. Le user stories aiutano a fondere quel feedback con le esigenze dell'utente finale in un modo che funzioni per tutti.
• Prevenire problemi prima che si presentino. Pensando come un utente, il team di sviluppo potrebbe individuare problemi che inizialmente erano stati trascurati. Questo dà loro l'opportunità di risolverli prima che il prodotto sia troppo sviluppato.

Migliori pratiche per le user stories

Anche se il formato per scrivere una user story è abbastanza semplice, è importante considerare diverse migliori pratiche quando si lavora su di esse.

• Concentrarsi sul perché, non sul cosa. La caratteristica stessa è importante nello sviluppo del prodotto, ma il motivo nella user story dovrebbe rimanere il motore principale dietro qualsiasi decisione. Chiarire le caratteristiche riguardo alle diverse esigenze degli utenti, piuttosto che la caratteristica specifica del prodotto.
• Sviluppare una migliore comprensione degli utenti. Per scrivere user stories efficaci, i team dovrebbero guardare a costruire personas utente dalla ricerca e dagli approfondimenti dei clienti. Questo rende le user stories più accurate rispetto all'esperienza vissuta.
• Prioritizzare e rivedere altre storie. Anche se alcune user stories non sono inizialmente utili, è una buona idea conservare il resto per il futuro, specialmente con nuovi prodotti che potrebbero subire ridisegni. È particolarmente utile quando i team di prodotto possono confrontare i dati reali dei clienti con le user stories.

Raccogli dati e feedback sui prodotti direttamente dai tuoi clienti, quindi organizza tutto per il tuo team interno utilizzando un software di gestione del feedback aziendale dedicato.