Cos’è una user story e come usarla

La user story è uno strumento ampiamente diffuso nei team Agile, con lo scopo di determinare quali funzionalità il team dei developer dovrà sviluppare. Inizialmente nato come strumento nell’Extreme Programming per facilitare lo sviluppo di prodotti digitali, spesso il modo in cui è implementato oggi lascia molto a desiderare.

In questo articolo vediamo cos’è una user story, a cosa serve, e quali sono i principi da seguire per ottenere il massimo vantaggio da questo strumento.

Cos’è una user story?

La user story è una breve descrizione della funzionalità di un prodotto, osservata dal punto di vista dell’utente. È importante ricordare che non si tratta di un documento onnicomprensivo, ma solo dell’annotazione di ciò che deve essere fatto.

Le user story hanno un formato standard:

Come [tipo di utente] voglio [azione da svolgere] così da [esito desiderato]. 

Questo formato è da intendersi come una linea guida. Esistono altri formati più recenti, come ad esempio i Jobs To Be Done, che possono essere utilizzati al posto delle user story.

Le user story non sono contratti scritti o requisiti, bensì brevi descrizioni di una funzionalità del prodotto. Per questo motivo, in un primo momento, è meglio omettere i dettagli, che potrebbero dare l’impressione alcune decisioni siano già state prese. I particolari andranno discussi e negoziati durante una conversazione tra i product manager, che fungono da portavoce degli utenti, e i developer.

Esempio:

Come acquirente voglio usare la carta di credito così da poter pagare il mio ordine.

Quando la funzionalità è stata discussa e alcune decisioni sono state prese, si possono aggiungere alle user story delle note che ricordano dettagli della conversazione avuta o vincoli che devono essere rispettati dai developer durante lo sviluppo.

Come acquirente voglio usare la carta di credito così da poter pagare il mio ordine.


Note: carte utilizzabili = Visa, Mastercard, American Express

Durante la discussione veranno anche a galla esempi di come il prodotto dovrà funzionare in situazioni specifiche. Anche questi dettagli dovrebbero essere raccolti e utilizzati in seguito come test che i developer utilizzeranno per verificare che la funzionalità sviluppata sia in linea con quanto richiesto.

Prova con carta di credito Visa, Mastercard e American Express (valido)
Prova con carta di debito (non valido).
Prova con carta di credito scaduta.
Prova con numero di carta valido/non valido/senza numero.

A cosa servono le user stories?

Il metodo delle user story nasce per portare l’utente al centro dello sviluppo del prodotto. Il loro scopo principale è di servire come promemoria per una conversazione che deve aver luogo tra product manager e developer riguardo una funzionalità del prodotto.

Prima della loro comparsa, i requisiti venivano di solito definiti a priori e si focalizzavano di più sulla soluzione concreta che sullo scopo che si voleva raggiungere. Questo limitava la capacitá di reagire a nuove informazioni ed era non di rado fonte di incomprensioni tra chi commissionava il prodotto e chi lo sviluppava.

Il passaggio a questo nuovo metodo ha favorito una maggiore flessibilità nella creazione dei prodotti e quindi maggiori possibilità di creare qualcosa di valore per l’utente. Inoltre ha radicalmente cambiato il modo di relazionarsi dell’utente con gli sviluppatori. Il continuo dialogo tra product manager (quale portavoce dell’utente) e developer permette di mantenere gli interessi dell’utente al centro dello sviluppo del prodotto e chiarire direttamente qualunque incomprensione.

Anche stories più tecniche devono essere scritte in modo tale che il vantaggio per gli utenti sia evidente. In questo modo sarà più facile per il product manager capirne il valore e prioritizzarle.

Chi crea le user stories?

Un product manager è il principale responsabile della creazione delle user stories. È uno dei lavori più importanti nello sviluppo del software perché il prodotto deve essere in linea con ciò che gli utenti vogliono per avere successo.

Una user story dovrebbe essere scritta in un modo che sia facile da capire, indipendentemente dal background di chi la legge. È quindi meglio evitare un linguaggio tecnico.

Anche se il product manager è il principale responsabile della creazione delle user story, la loro discussione è un processo collettivo e sta a ciascuno dei membri del team prendere nota delle decisioni che prese in modo da avere tutte le informazioni necessarie durante la fase di sviluppo.

È quindi non solo compito del product manager, ma anche dei developer o di chiunque sia coinvolto nel processo di sviluppo e test aggiungere annotazioni per ricordare meglio quanto definito durante la discussione della user story.

Come scrivere una buona user story

Come abbiamo visto, una user story deve essere un documento semplice e sintetico, ma allo stesso tempo molto preciso. È bene iniziare con un obiettivo chiaro in mente, ovvero quale scopo si vuole ottenere con la funzionalità descritta.

In genere le user story diventano più accurate e vengono scomposte in più parti man mano che ci si avvicina allo sviluppo. Non è necessario, né raccomandabile, fare questo lavoro per funzionalità che sapremo andremo a sviluppare a distanza di diversi mesi, quando le informazioni che avremo o il contesto saranno molto probabilmente cambiati. Inoltre, è meglio tralasciare il più a lungo possibile qualunque riferimento tecnico o all’interfaccia utente, in modo da non contaminare il processo creativo proponendo una soluzione troppo in anticipo.

Per quanto riguarda invece le user story con un’orizzonte temporale limitato (da una a sei settimane), la regola di base è mantenerle abbastanza contenute da poter essere realizzate all’interno di uno Sprint. Nel caso in cui questo non fosse possibile, è meglio suddividere la funzionalità in due o più user story, cercando di strutturare ciascuna in modo che costituisca una funzionalità completa e testabile.

Come abbiamo visto, uno dei vantaggi principali di questo metodo è mettere l’utente al centro dell’attenzione nel momento di sviluppo di un prodotto. Per questo motivo se, come spesso è il caso, il prodotto è utilizzato da più utenti diversi, è bene specificare di quale utente si parla. Questo darà una visione più completa ai developer dello scopo della funzionalità.

Un’altro punto importante da ricordare nello scrivere una user story è utilizzare sempre la forma attiva.

Secondo Mike Cohn, autore della miglior guida sull’argomento User Stories Applied, una buona user story:

• è indipendente
• è negoziabile
• ha valore per gli utenti o gli acquirenti del prodotto
• può essere stimata dai developer
• è breve
• può essere testata

Quanto lunga dev’essere una user story?

Le user story sono promemoria di una conversazione che deve aver luogo tra product manager e developer, quindi é preferibile che siano brevi e incisive.

Se però ci sono dettagli rilevanti, questi possono essere aggiunti come annotazioni. Le note servono a riprendere le conversazioni in un secondo momento senza dimenticare quanto è stato già discusso e deciso.

Attenzione a non esagerare con i dettagli. La ricchezza di particolari potrebbe sembrare un segno di precisione, ma spesso specificare i dettagli troppo presto crea solo confusione e un maggior carico di lavoro. Tanti dettagli danno infatti l’idea che la storia sia già stata discussa e stimata con accuratezza, portando all’impressione che non ci sia bisogno di discutere ulteriormente e, nel peggiore dei casi, allo sviluppo di una funzionalità che non soddisfa quanto richiesto.

Errori comuni da evitare

Uno degli errori più comuni è quello di scrivere user story troppo lunghe e ricche di dettagli. Nel dubbio è meglio mantenersi il brevi e aggiungere in seguito, se necessario, alcune note per specificare quanto non è chiaro.

Il rischio è che le user story diventino dei documenti formali volti a misurare il progresso dello sviluppo di un prodotto. Questo non è il loro scopo, che come abbiamo visto è solo di ricordare al team di avere una discussione a riguardo. Use cases, scenari e manuali tecnici sono gli strumenti più adatti a soddisfare questo scopo.

Un altro errore da evitare è che i developer riscrivano le user story con linguaggio tecnico. Questo metodo crea di fatto due vie di comunicazione parallele che servono solo a creare incomprensioni. I dettagli tecnici devono naturalmente essere scritti, ma come note.

Per funzionalità molto tecniche è facile dimenticarsi dell’utente e succede spesso che le user story vengano scritte per i developer. In questo caso è meglio riformulare la frase in modo che il vantaggio per l’utente sia chiaro.

Conclusioni

Una buona user story è breve e volutamente imperfetta.

Anche se fosse possibile scrivere requisiti perfetti, il problema è che gli utenti cambiano le loro opinioni man mano che acquisiscono nuove informazioni e un insieme “perfetto” di parti non creare necessariamente un tutto efficace.

È meglio quindi riconoscere e accogliere i propri limiti e concentrarsi sul dialogo con il team e sul raggiungimento di un livello di comprensione condiviso.