Come scrivere una User Story

Data : 11/02/2020| Categoria: FAQ| Tags:

Cos’è una User Story? Definizione

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.

user story scrum agile

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:

  1. Scenario oriented: Given/When/Then
  2. Rule-oriented: checklist template
  3. 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.

Come pianificare uno sprint agile? Leggi il blog post 3 consigli per pianificare gli sprint del tuo progetto agile.

*INVEST in Good Stories, and SMART Tasks

Copyright ©  2019 Agile Business Consortium all rights reserved

Condividi l'articolo, scegli la piattaforma!

Newsletter

Iscriviti alla newsletter di QRP International per ricevere in anteprima news, contenuti utili e inviti ai nostri prossimi eventi.

   
   

QRP International userà le informazioni che scriverai nel form per restare in contatto con te. Vorremmo continuare ad aggiornarti con le nostre ultime news e con contenuti esclusivi pensati per supportarti nel tuo ruolo.

       
       

Puoi cambiare idea in qualsiasi momento cliccando il link "unsubscribe" dal footer di una delle email che riceverai da noi o scrivendoci a marketing@qrpinternational.com. Tratteremo le tue informazioni con rispetto. Per maggiori informazioni sulle nostre privacy policy puoi visitare il nostro sito web. Cliccando in basso, accetti che potremo utilizzare le tue informazioni in conformità con questi Termini & Condizioni.

We use Mailchimp as our marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.