Le User Story rappresentano una pratica Agile, utilizzata soprattutto in Scrum, per “catturare” le esigenze degli utenti esprimendo in maniera generale, non dettagliata, caratteristiche, funzioni e requisiti per il prodotto da realizzare.
Sono un elemento del Product Backlog , che in Scrum rappresenta una “lista” di tutte le cose che devono essere realizzate nel progetto.
Sono un elemento all’apparenza semplice, ma veramente efficace in quanto consentono di focalizzarsi su necessità e bisogni dell’utente (e/o cliente) e sul valore da realizzare.
Le user story vengono spesso scritte su cartoncino o post it, vengono attaccate al muro o su tavoli per agevolare la pianificazione e discussione. In questo modo riescono a spostare l’attenzione dallo scrivere le feature al discutere riguardo le feature, dimostrando l’importanza dell’affermazione del Manifesto Agile “il software funzionante più che la documentazione esaustiva”.
User Story Agile: a cosa servono?
Le User Story sono un ottimo modo per definire il prodotto/servizio in maniera chiara. Un insieme di user story ben scritte e prioritizzate può sicuramente aiutare il team a esprimere e condividere le funzionalità del prodotto senza scendere in dettagli tecnici.
Una user story consente di capire l’importanza e l’impatto di una funzionalità sul business e aiuta a far capire anche al cliente l’utilità della funzionalità e la sua priorità.
Se ben scritte, le user story forniscono delle solide basi per la comunicazione e collaborazione, portando al centro dell’attenzione l’utente. L’utilizzo delle user story facilita discussioni sul prodotto, sia all’interno del team di sviluppo sia con gli stakeholder esterni.
Composizione di una user story
Ogni storia descrive cosa fare, per chi e perché in maniera semplice, comprensibile allo stesso modo per il cliente e per gli sviluppatori. Il punto di vista è quello di chi richiede la nuova funzionalità, la quantità di informazioni è quella indispensabile per consentire al team di sviluppo di fare una stima di massima del lavoro richiesto per la realizzazione.
Ci sono diversi modi di scrivere una user story ma solitamente contiene un nome, una breve descrizione e la specifica dei criteri di accettazione e delle condizioni per cui la story possa ritenersi completata.
User story: esempio
Un modello può essere:
As a <type of user>, I want <some goal> so that <some reason>.
In italiano potrebbe essere: In qualità di <tipologia di utente>, voglio <una specifica funzionalità>, così che/per <valore/vantaggio>.
Ecco due esempi:
In qualità di cliente voglio cancellare la mia prenotazione hotel, per poter avere un rimborso
In qualità di cliente online, voglio poter fare login per accedere con sicurezza al mio account.
La storia rende necessario il dialogo con il cliente e/o utente, perché è grazie al dialogo che riusciamo a capire tutti i vari aspetti della storia, possiamo avere una buona conoscenza del dominio e del perché dobbiamo sviluppare quella specifica funzionalità.
Caratteristiche fondamentali delle user story
Le user story dovrebbero sempre avere 6 caratteristiche, rappresentate dall’acronimo INVEST, utilizzato da Bill Wake*:
Independent: devono essere indipendenti tra loro
Negotiable: devono essere “negoziabili” ed aperte ai contributi di tutti
Valuable: devono portare valore aggiunto al cliente
Estimable: devono essere stimabili, non in maniera esatta, ma abbastanza da poter permettere una pianificazione di massima per l’implementazione
Small: devono essere piccole, in modo da riuscire a realizzare la funzionalità in massimo un paio di settimane di lavoro. Devono essere piccole perché in questo modo le stime sono più precise. Se la story è troppo complessa, la scompongo in più story.
Testable: devono poter essere testate e devono avere informazioni su come eseguire i test.
In basso un esempio di come scomporre una user story in user story più semplici.
Chi scrive le user story?
Le user story possono essere scritte da chiunque abbia le competenze necessarie per scriverle. Molto spesso vengono scritte dal Product Owner. Oppure possono essere scritte dall’intero team in collaborazione.
Acceptance criteria
Insieme alle user story è importante elaborare degli acceptance criteria, ovvero dei criteri che devono essere utilizzati per valutare se una storia è stata implementata correttamente e pienamente. Si tratta quindi delle condizioni che il prodotto software deve rispettare per essere accettato dall’utente e/o cliente. Gli acceptance criteria sono fondamentali per capire quando l’obiettivo della user story viene raggiunto.
Gli acceptance criteria possono essere di tre diverse tipologie:
Scenario oriented: Given/When/Then
Rule-oriented: checklist template
Custom format
Acceptance criteria – esempi
Vediamo due esempi di acceptance criteria.
User story 1: L’utente ha dimenticato la password per effettuare il login sulla piattaforma
Scenario 1: L’utente ha non ricorda la password di login
Given: L’utente naviga sulla pagina di login
When: L’utente seleziona <password dimenticata>
And: Inserisce un indirizzo di email valido per ricevere il link per ripristinare la password
Then: Il sistema invia il link per ripristinare la password all’indirizzo email
Given: L’utente riceve il link per email
When: L’utente clicca sul link rivecuto
Then: Il sistema permette all’utente di impostare una nuova password
User story 2: L’utente ha necessità fare ricerca di prodotto sul sito e quindi è necessario che sia presente un campo per eseguire tale ricerca
Scenario 2: L’utente cerca oggetti da acquistare
Given: L’utente è già registrato per poter effettuare l’acquisto
When: L’utente apre la pagina “Prodotti”
And: Il sistema mostra il campo ricerca in alto al centro dello schermo
Then: Il sistema mostra all’utente una lista di prodotti
When: L’utente inserisce nel campo ricerca le opzioni che preferite
And: L’utente clicca il bottone “Conferma”
Then: Il sistema mostra i prodotti che corrispondono alle parole usate nella sezione “Risultati di ricerca”
And: Il sistema mostra il numero di risultati nella sezione “Risultati di ricerca”
Formato
La user story viene spesso scritta su una scheda di carta formato A6. Il formato piccolo obbliga a non usare troppo informazioni. La carta è utile perché è facile da usare e rende possibile raggruppare le card al muro o sul tavolo per poter valutare la consistenza, completezza e le connessioni tra diverse story. Anche se hai story elettroniche, può essere utile utilizzare dei cartoncini.
Un altro fattore importante è la visibilità: le story devono essere visibili a tutto il team. In fondo rappresentano l’unità di lavoro che il team si impegna a realizzare in uno sprint.
