User Story. Il loro nome così narrativo ci porta a volare lontano con la fantasia ma siete davvero sicuri che si tratti di storie fantastiche? Andiamo fino in fondo (alla storia) e scopriamo cosa sono le User Story e come si realizzano.

Se il termine non vi suona poi così nuovo un motivo c’è. Andando indietro di qualche post, nel testo su Scrum e Kanban le troverete citate. Abbiamo infatti parlato di loro in relazione alla Product Backlog, che in Scrum rappresenta appunto la lista di tutte le cose in ordine di priorità da realizzare. 

Le User Story, cosa sono.

Le User Story sono delle brevi descrizioni narrative dei task costruite su ciò che l’utente immaginiamo possa compiere durante l’interazione con un servizio digitale. Efficaci e importanti, consentono di focalizzarsi sui bisogni dell’utente e sul valore da realizzare. Si condividono con il team di sviluppo, stabilendo così cosa deve essere implementato o no. 

Ciò che le rende davvero rivoluzionarie è però ancora altro. Le User Story pongono infatti lo User (l’utilizzatore del prodotto) al centro del processo di sviluppo e con lui la Story, ovvero i bisogni che ogni funzionalità permette di soddisfare. 

User Story, a cosa servono.

Le User Story servono a definire in modo chiaro un prodotto/servizio. Forniscono solide basi su cui poter discutere e collaborare, sia lato team che consumatore. Infatti se scritte bene e secondo un ordine di priorità, aiutano molto il team a confrontarsi e condividere le funzionalità del prodotto senza scendere nei dettagli tecnici. Lato cliente, ovvero User, consentono invece di far capire l’utilità della funzionalità da sviluppare e perché è così importante.

User Story, come si scrivono. 

Ma passiamo adesso al dunque, a come si scrive effettivamente una User Story. Ogni storia si basa su tre punti principali, espressi in modo semplice e comprensibile sia per il cliente che gli sviluppatori. Quali sono? Cosa fare, per chi e perché. 

Quindi in uno schema potremmo riassumere così la struttura della User Story:

Come in qualità di User (As a type of User)

Voglio una specifica funzionalità o azione (I want some goal) 

In modo che, obiettivo, valore (so that some reason).

Bene, adesso mettiamoci alla prova e facciamo un esempio pratico e efficace con la seguente User Story:

Il primo punto si focalizza sull’User: chi stiamo servendo? Chi è il nostro User? Se facciamo riferimento alla nostra User Story per esempio potrebbe trattarsi di un utente alla prima visita sul sito come di un utente già registrato. Ogni prodotto ha una varietà di utenti diversi, non esiste un utente unico. 

Anche la funzionalità può servire a diversi utenti con differenti finalità. E qui fate molta attenzione. Considerando sempre la nostra User Story il login mi permette di salvare e accedere velocemente alle mie informazioni ma anche proteggere con un nome e una password i miei dati. Le User Story però ci mettono davanti alle priorità e a scegliere la funzione più importante. Se dovete sviluppare una funzionalità per due bisogni diversi scrivete due User Story: ciò manterrà chiarezza nella comunicazione e priorità nell’azione. Con l’Agile potrai rilasciare poco e spesso, testare l’utilità di quanto sviluppato, apportare valore all’User: non ti perdere, resta concentrato sulle priorità. 

User Story, le fondamentali caratteristiche.

Le User Story dovrebbero sempre rispondere a queste sei caratteristiche:

• Independent: essere indipendenti tra loro

• Negotiable: essere negoziabili e quindi aperte a confronti e contributi di tutti

• Valuable: portare valore all’User

• Estimable: stimabili, quindi costruite con chiarezza e seguendo un ordine prioritario così da permettere una pianificazione di sviluppo e implementazione

• Small: piccole e di immediata comprensione, così da realizzare la funzionalità in poche settimane e rilasciarla. Si scrivono di solito in formato A6, sia in cartaceo che digitale. 

• Testable: devono essere testabili.

User Story, chi le scrive. 

Non c’è una regola fissa, le User Story possono essere scritte sia dal Product Owner che dal team stesso, collaborando. 

Ma cosa succede una volta che abbiamo la User Story scritta?

Il primo passo è il confronto e la discussione con il team che si occuperà di svilupparla. Nella riunione emergono domande e dettagli che si aggiungono alla User Story e prendono il nome di Acceptance Criteria, ovvero i criteri di accettazione che permettono di verificare se una funzionalità è stata implementata come era stato deciso oppure no (spesso non è così). 

I Criteri di Accettazione e lo stile della User Story cambiano a seconda del team, cambiano da persona a persona. Torniamo al nostro esempio, alla nostra User Story.

Acceptance Criteria aggiunti da Pippo

Primo Scenario: l’User prova a loggarsi con le sue corrette credenziali 

-Dato mi trovo nella pagina relativa al login ma al momento non sono loggato 

-Quando inserisco i dati corretti e clicco sul bottone login 

-Il sistema mi riconosce e logga.

Secondo Scenario: l’User prova a loggarsi con le sue credenziali sbagliate

-Dato mi trovo nella pagina relativa al login ma al momento non sono loggato 

-Quando inserisco i dati sbagliati e clicco sul bottone login 

-Il sistema non mi riconosce e mi nega il login.

Acceptance Criteria aggiunti da Pluto

Primo Scenario: l’User accede al sito facendo il login correttamente 

-L’user non loggato accede alla pagina del login

-Inserisce l'username e la password 

-clicca sul bottone login 

-Il sistema lo riconosce e lo fa accedere al proprio account personale

oppure

-Nega il login e mostra messaggio username o password errata facendo riprovare di nuovo.

Dalla stessa User Story due stili diversi.