Oggi parliamo di storie, un grande classico per i product owner, e andiamo alla base della loro costruzione esplorando insieme le 3 C delle user stories: carta, conversazione e conferma.
Ma cosa sono le user stories? Sono semplici descrizioni, contenute in una frase, di ciò che un determinato utente vuole ottenere raccontate dal suo punto di vista.
Sono nate nell’ambito dell’Extreme Programming prima dell’inizio di questo millennio (la loro origine si fa risalire al 1998) e sono poi diventate popolari in tutti i processi agile.
User story: qualche esempio di scrittura delle card
Facciamo qualche esempio pratico per capirci meglio.
Immaginiamo di stare sviluppando un sito di annunci (i cosiddetti classified) che consente a venditori e acquirenti di scambiarsi beni materiali e servizi accordandosi tra privati.
La nostra piattaforma avrà user stories come queste:
- come utente di <nome della piattaforma> , posso effettuare ricerche su articoli specifici.
- come venditore, posso facilmente consultare la lista di tutti i potenziali acquirenti interessati al prodotto che ho messo in vendita.
Come vedete sono frasi brevi che descrivono cosa un utente vuole fare, raccontate secondo il suo punto di vista.
Un’altra cosa che possiamo notare è che abbiamo più tipologie di utenti: nel primo caso parliamo di un utente generico, nel secondo adottiamo il punto di vista di uno dei principali attori della piattaforma (in venditore).
Possiamo fare la stessa cosa mettendoci dal punto di vista dell’acquirente:
- come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo.
Cosa manca ancora in questo esempio?
Manca un dettaglio che per me è la parte più importante delle user stories, la cosiddetta clausola so-that.
Ciò che spiega perché un determinato utente vuole una certa cosa, qual è la sua finalità, qual è il risultato finale a cui tende (o outcome).
La storia potrebbe prendere allora questa forma:
“come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo così da potermi accertare delle sue condizioni”
O dal punto di vista del venditore:
“come proprietario di un auto che desidero vendere, posso creare una pagina in cui descrivere lo stato dei veicolo e mostrarlo al suo meglio”
Notate che stiamo parlando della medesima funzionalità (le foto associate al prodotto) da due punti di vista differenti: quello del venditore e quello dell’acquirente.
User story: l’importanza del punto di vista
Bene, abbiamo introdotto il formato più classico con cui si scrivono le user stories:
Come <tipo di utente>, voglio <funzionalità> così da <obiettivo o valore per l’utente>.
Semplice ed efficace! Chiunque è in grado di esprimere un bisogno, una necessità o un desiderio secondo questo formato.
Ma non è solo la semplicità ad essere la chiave del successo delle user stories, l’elemento essenziale qui è la prospettiva: il punto di vista che adottiamo ci aiuta a relazionarci con specifiche tipologie di utenti, a metterci nei loro panni.
Sembra un dettaglio ma non lo è.
Ditemi se vi fa lo stesso effetto esprimere le medesime funzionalità come si descrivevano una volta nei documenti di requisiti …
- il sistema consente all’utente di effettuare una ricerca
- il sistema consente all’utente di pubblicare online un prodotto
- il sistema consente all’utente di associare una o più foto a un prodotto
Il significato di queste affermazioni è lo stesso ma nel primo caso rispondiamo con più empatia perché stiamo mettendo l’utente – una persona – al centro della scena.
User story: la conversazione a partire dalla carta
Un errore in cui cadono spesso i team che muovono i primi passi con i framework agili è pensare che una volta scritta la user story tutto sia chiaro e definito.
In realtà chi ha un po’ più di esperienza alle spalle sa bene che la scrittura è solo l’inizio del gioco.
Non dobbiamo dimenticare che la user story comprende tre C:
- una scheda o carta (= card),
- la conversazione (= conversation)
- criteri di conferma (= confirmation).
Le 3 C sono un’allitterazione ideata da Ron Jeffries per chiarire che una user story è più di un semplice testo scritto su carta fisica o su strumento software.
Le user stories sono brevi, non sono fatte per contenere molti dettagli bensì per agevolare delle conversazioni (si parla anche delle storie anche come “placeholder per conversazioni con il team”).
La carta è solo una delle tre C, la più visibile, e anche quella meno importante.
Mi è capitato in passato di lavorare con team che pretendevano di avere il massimo livello di dettaglio nelle storie; questo desiderio di chiarezza e completezza per quanto comprensibile dà l’illusione che tutto sia stato definito e compreso ma non aiuta le persone ad uscire dalla propria comfort zone e fare il “viaggio di scoperta” nei bisogni dell’utente.
E’ dall’interazione tra il product owner, il team allargato e gli utenti che nasce la vera comprensione di ciò che c’è da fare, non da una frase scritta su un pezzo di carta.
Non si tratta di un modo alternativo di scrivere requisiti, la card è “una promessa a due vie” come dice Mike Cohn:
- la promessa del team di porre domande prima di iniziare a lavorare su una storia
- la promessa del product owner di essere disponibile ad approfondire l’argomento.
Questi due aspetti insieme ci evitano di dover scrivere corposi documenti di specifiche contenenti ogni singola funzionalità.
Se il team si parla prima di iniziare a lavorare, il product owner può specificare solo quanto basta per poter avere quella conversazione.
E’ la conversazione in sé che rende agile un team, non la scrittura delle storie, l’utilizzo di post-it o di tool come Jira.
User story: la C di conferma
Quando Mike Cohn illustra questa parte delle storie dice che non gli piace iniziare qualcosa se non capisce come saprà quando ha terminato. E a chi piace questa incertezza?
I criteri di conferma di una user story servono proprio a questo; sono il modo in cui il product owner definisce insieme al team ciò che deve essere fatto affinché lo sviluppo possa essere considerato completo.
Ricordate quando a scuola per la prima volta un insegnante vi ha assegnato un riassunto di un libro? Alzi la mano chi non si è chiesto quanto dovesse essere lungo lo scritto!
Ecco, questo è un classico esempio di criterio di accettazione. Per alcuni professori una sintesi di una pagina è accettabile, per altri non si parla di sufficienza sotto le 3 pagine (e non pensate di barare con la dimensione del testo e l’interlinea!).
Una parte della conversazione tra il team e il product owner prima di lavorare una storia riguarderà proprio i criteri di conferma, ovvero come ciò che sarà sviluppato verrà valutato per l’accettazione durante la sprint review.
Si tratta delle “condizioni di soddisfazione” della storia. In altre parole, affinché il product owner possa considerare la user story fatta, una determinata cosa deve fare questo, quello e quell’altro.
Torniamo al nostro esempio di prima quando parlavamo della possibilità di associare delle foto all’auto che il nostro utente vuole mettere in vendita.
Per questa user story potremmo definire criteri di accettazione di questo tipo:
- i formati di immagine accettati dal sistema (es. jpg, png, ecc.)
- il peso massimo della singola immagine
- la possibilità di vedere un’anteprima dell’immagine caricata
- e magari anche la possibilità di poter ruotare eventuali immagini capovolte prima della pubblicazione.
User story: la prima C da sola non basta!
Siamo arrivati alla fine del nostro excursus sulle user stories.
Come abbiamo visto le storie non sono un nuovo modo di scrivere i requisiti, ma molto di più. Hanno come minimo 3 funzioni:
- sono un placeholder per una conversazione sui bisogni degli utenti
- sono strumenti per capire cosa vogliono gli utenti e cosa ha senso realizzare
- sono un modo per programmare il lavoro del team.
Quindi ricordatevi di prestare attenzione a tutti e 3 gli aspetti: non solo al testo che andrete a scrivere su una scheda, ma anche alle conversazioni sulla funzionalità e ai criteri di conferma che utilizzerete per determinare se la storia è completa.
Note
Questo post è liberamente tratto dalle lezioni di Mike Cohn sulle user stories. Se volete approfondire vi consiglio il suo corso – molto valido – “Better User Stories“.
Nel blog trovate anche diversi post dedicati alle storie. Eccone qui una piccola selezione:
