Le 3 C delle user stories: carta, conversazione e conferma

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:

Perché investire nella strategia di prodotto

La scorsa settimana ho parlato di visione strategica, di cosa sia e quanto sia rilevante per l’allineamento di tutte le iniziative in azienda rifacendomi al framework della Core Strategic Vision.
Oggi voglio invece approfondire un elemento su cui la visione strategica aziendale ha un impatto determinante: la strategia di prodotto.
Su questo argomento ci viene in aiuto Roman Pichler con i suggerimenti contenuti nel volume “Strategize” pubblicato nel 2016.

Visione e strategia di prodotto

Cosa indica il termine “strategia”?
Un piano d’azione per raggiungere un obiettivo a lungo termine.
Pianificare il successo di un prodotto comporta secondo l’autore due aspetti:

  1. trovare la giusta strategia di prodotto
  2. decidere come implementarla.

Nel primo ambito i due elementi chiave sono la visione e la strategia di prodotto; in fase di esecuzione la product roadmap e il product backlog (di cui abbiamo parlato qui).

La visione è la ragione ultima per creare il prodotto e deve essere coerente con la Core Strategic Vision dell’azienda. Descrive il cambiamento positivo che il prodotto porta e risponde alla domanda “perché questo prodotto esiste?”.

La strategia di prodotto descrive come l’obiettivo a lungo termine è raggiunto: include la value proposition del prodotto, il posizionamento di mercato, le principali caratteristiche e gli obiettivi di business. Indica insomma come la vision viene realizzata.

La product roadmap mostra come la strategia di prodotto viene eseguita definendo le principali release con specifica di date, obiettivi e funzionalità.
Infine il backlog contiene tutti i dettagli necessari per sviluppare il prodotto come indicato dalla roadmap con epiche, user stories e altri requisiti.

Se volete qualche dettaglio operativo su come derivare il backlog di prodotto dalla product vision vi consiglio di utilizzare la vision board.

Gli elementi della strategia di prodotto

La strategia di prodotto guarda alla “big picture”, non ai dettagli.
Il piano di alto livello che aiuta a realizzare l’obiettivo finale deve spiegare a chi è destinato il prodotto è perché le persone vogliono acquistarlo e utilizzarlo; che cos’è il prodotto e in che cosa è differente dagli altri; quali sono gli obiettivi di business e perché per l’azienda ha senso investire in esso.

Gli elementi della strategia di prodotto sono quindi 3:

  1. il mercato e i suoi bisogni
  2. gli obiettivi di business
  3. le funzionalità chiave e gli aspetti differenzianti.

Il mercato descrive il target e gli utilizzatori del prodotto, le persone che hanno maggiore probabilità di acquistarlo e usarlo; i bisogni comprendono i problemi che il prodotto risolve o il principale beneficio che produce.
Abbiamo parlato a lungo di questi aspetti in relazione alle Personas se ricordate.

Il business goal definisce come il prodotto genererà valore per l’azienda. Anche su questo aspetto ci siamo già soffermati in passato parlando di come possiamo definire più dettagliatamente il valore.
Nella maggior parte di casi si parla di generare ricavi, ma un prodotto potrebbe produrre valore anche supportando la vendita di altri prodotti o servizi, riducendo i costi o facendo aumentare il valore del marchio. A seconda dell’obiettivo sceglieremo il corretto KPI per misurare il valore generato dal prodotto.

Le key features sono quegli aspetti del prodotto cruciali nel creare valore per i clienti e gli utilizzatori, le funzionalità che lo fanno scegliere dal pubblico al posto delle altre alternative di mercato.

La product strategy può cambiare?

Proviamo a contestualizzare quanto detto sinora.
Abbiamo detto che la vision è la ragione ultima per creare il prodotto e descrive il cambiamento in positivo che il prodotto vuole generare.
Pichler fa l’esempio di una app che aiuti le persone a diventare consapevoli di cosa, quando e quanto mangiano.

La vision in questo caso può consistere nell’aiutare le persone a fare una vita più salutare; la strategia è creare una app che monitori l’assunzione di cibo tramite alcuni device quali uno smartwatch, una banda fitness e una bilancia smart.

Intanto notate come una visione di questo tipo – aiutare le persone a fare una vita più salutare – abbia maggior potere di ispirare rispetto al semplice obiettivo di “perdere peso” (una visione efficace deve essere grande!).
L’altro aspetto fondamentale è questo: la vision non cambia nel tempo, ma la product strategy può cambiare.

Tornando all’esempio di prima se la app non si rivela lo strumento giusto per aiutare le persone a fare una vita più salutare si possono provare altre strade per raggiungere l’obiettivo: scrivere un libro, creare una community di influencer, ecc.

Quando la vision manca…

Abbiamo più volte ribadito che la strategia di business deve dirigere quella di prodotto e che la company vision influenza la visione del prodotto.
L’autore di “Strategize” è proprio diretto quando scrive:

“Se il tuo business non ha una strategia generale o se non ne sei consapevole, rimanda la formulazione di una strategia di prodotto fino a quando la business strategy non è disponibile.
A meno che tu lavori per una start-up, in qual caso il business e la strategia di prodotto è molto probabile che siano identici”.

L’autore ci suggerisce anche un possibile espediente quando si verifica una situazione di questo tipo. L’idea è di mettere insieme i principali stakeholder, fare formulare loro prima individualmente la vision del prodotto e poi condividerla nel gruppo.
Si tratta di un esercizio molto potente che consente di guardare cosa hanno in comune le visioni di ciascuno e di creare una strategia di ampio respiro, condivisa e di ispirazione.

Sono più chiari adesso i benefici di una strategia di prodotto?
La finalità è massimizzare le chance di successo del prodotto stesso.

La strategia è il nodo chiave tra la visione in alto e l’esecuzione in basso: indica la direzione a cui puntare in linea con la vision aziendale più generale e allo stesso tempo indirizza il processo di discovery permettendo di scoprire i giusti dettagli di prodotto.
E poi, cari Product Owner, deve ispirare voi e le persone che lavorano con voi!
Deve avere la capacità di coinvolgere e farvi venire la voglia di rimboccarvi le maniche.
Un po’ come dice Pichler che va dritto al punto ed è sempre per me di grande ispirazione :

“Life is too short to work on products
you don’t believe in”.


Backlog declutter 2: come mettere ordine tra le user stories

Come scegliere i requisiti da tenere seguendo il criterio della felicità… dei clienti!

Questa è la seconda parte di un post dedicato al declutter del backlog.
Qui, se ve la siete persa, trovate la prima parte.

Ci siamo lasciati parlando di user stories che hanno campeggiato troppo a lungo nel product backlog senza mai essere state portate in priorità. 
Vediamo quali altri casi sono buoni candidati per l’eliminazione.

Le user stories che ho nel mio backlog  hanno individuato un soggetto reale?
Stiamo parlando di persone o di moduli?
Si tratta di un’attività di valore?
Abbiamo individuato un reale bisogno o solo una soluzione tecnica?
Queste storie sono ottimi spunti per fare pulizia.
E poi la coerenza con la strategia generale. Potremmo avere in realtà degli item così vecchi che sono ormai superati perché le strategie aziendali hanno preso una direzione differente.

Sono tutte considerazioni che possiamo fare.
Non temete di eliminare troppo, non rimarrete mai senza nulla…
Se invece vi sentite sopraffati dall’impresa non scoraggiatevi. 
C’è sempre chi ha affrontato di peggio, come nel caso di una transizione a LESS in cui si è passati da 508 item a 23 user stories. Qui probabilmente si erano spinti un po’ troppo in là con la granularità, però è un buon esempio del fatto che è possibile fare un’operazione significativa di pulizia. 
Come? Seguendo gli step che stiamo percorrendo noi… hanno fatto un lavoro colleggiale, hanno stampato tutti gli item e li hanno classificati, che è esattamente il passo successivo.

Adesso con tutte le card davanti a noi concentriamoci su quali criteri utilizzare nel processo di eliminazione.

Categorizzare le user stories

Per fare ordine dopo la fase dell’eliminazione si passa al categorizzare. 
Riordinare per categoria è un altro principio cardine nella gestione del clutter fisico. 
Non si riordina stanza per stanza ma categoria per categoria: vestiti, libri carte, ricordi.
Andremo a individuare delle categorie e a classificare gli item uno alla volta. 
Ognuno di voi dovrà trovare il criterio che meglio si adatta al proprio caso. 

Ecco qualche idea: categorizzate per epiche, step dello user journey, impatti, stakeholder o obiettivi di business. Potete focalizzarvi sul contenuto, sul valore, sugli interlocutori e molto altro. 
Il mio consiglio fondamentalmente è di provare varie classificazioni e vedere quella che meglio si adatta al vostro caso. Personalmente ho iniziato utilizzando gli step del processo poi mi sono resa conto che non era esattamente ciò di cui avevo bisogno, era troppo vincolante mentre mi sono trovata molto meglio con quelli focalizzate sulla parte dei contenuti.

Mettere a confronto

Una volta che siete riusciti a categorizzare le vostre storie dovete fare un lavoro all’interno di ognuna di queste categorie e procedere per confronti.
In sostanza avete definito dei sotto raggruppamenti nel backlog e in ognuno di questi fate un lavoro di prioritizzazione.
Potreste scoprire anche in questa fase che qualcosa può essere ancora eliminato. Ad esempio se provassimo a vedere ognuna di queste categorie attraverso il principio di Pareto qual è il 20% delle user stories che producono 80% del valore?
Quali sono dei must? Quali should o could?
Siamo in grado di individuare i must-have per gli utenti e quelle storie che invece possono fare la differenza ed essere dei delighters?
Trovate il focus!
Provate a riconsiderare ognuna di queste categorie sulla base di varie tecniche di prioritizzazione. Più una… che ho tenuto a parte.

La felicità come criterio di scelta

Questa è un’idea mutuata proprio dal declutter: non dovremmo scegliere che cosa buttare bensì scegliere cosa tenere. E il criterio in questo caso è conservare solo ciò che ci rende felici, che ci fa sentire bene, che ci risuona emotivamente.
Non voglio prendere una deriva new-age fricchettona, dico solo che questa idea può essere trasposta nella gestione del backlog.
Quanta felicità una determinata storia porta ai nostri utenti?
In una scala di felicità siamo sicuri che l’ordinamento che ci siamo dati sia quello corretto? Riesco a produrre un impatto significativo nei miei utenti?

Continuare a prendersi cura

Bene una volta che abbiamo fatto questo repulisti, abbiamo organizzato i nostri item per categorie e abbiamo dato anche un ordine di priorità guardiamo con un occhio più attento ogni singolo elemento che abbiamo conservato.

Dobbiamo verificare che sia tutto effettivamente in ordine. Andare a vedere se ognuno di questi item che abbiamo conservato è completo, ha la struttura corretta, se abbiamo individuato realmente chi sono gli interlocutori e quali sono i loro bisogni.
E capire se sono coerenti con lo scenario attuale.

Una delle cose che si possono fare è focalizzarsi sulla prossima release di prodotto e cercare di associare al backlog una roadmap di prodotto per gli sviluppi più avanti nel tempo. 
Anche qui facciamoci delle domande per verificare che effettivamente quello che abbiamo conservato sia in buono stato: abbiamo tenuto conto di tutti gli interlocutori?
Abbiamo individuato bisogni espliciti ed impliciti?
Tutto questo è coerente con la strategia più generale?

Dopodichè non ci resta che…

Evitare le ricadute

Bisogna evitare di tornare nella situazione dalla quale siamo partiti. Come possiamo farlo? Dobbiamo avere attenzione nei confronti di ciò che a questo punto entra all’interno del backlog. E qui possiamo cogliere diversi spunti.
Diamoci una finestra temporale. In un armadio teniamo i vestiti per la stagione in corso, perché non nel backlog?
Facciamo in modo che il nostro backlog sia focalizzato sui prossimi tre mesi massimo sei mesi magari.

Utilizziamo un criterio che definisca esattamente che cosa è pronto per il backlog e tutto quello che non lo è può essere inserito in una sorta di waiting box / may be box (un contenitore dove inseriamo tutta una serie di buone idee da cui potremmo andare a pescare successivamente).

Teniamo sott’occhio la ratio delle cose che entrano ed escono oppure diamo un limite esplicito al nostro backlog. Alcuni ad esempio si impongono una certa soglia oltre la quale non andare proprio perché appunto la visione complessiva del backlog si sfilaccia.

Vedere l’ordine

Un altro suggerimento che potrebbe esservi d’aiuto nel mantenere l’ordine è tenere sotto controllo il backlog utilizzando diverse modalità di visualizzazione.

Chi ha letto il libro di Marie Kondo sa che uno dei consigli più preziosi e totalmente controintuitivi è disporre gli indumenti nei cassetti in un modo diverso che uno sopra l’altro bensì in verticale.


Questa idea mi ha fatto riflettere e mi sono resa conto che a volte siamo troppo condizionati dalla strumento che utilizziamo per gestire il backlog.
Proviamo ad andare oltre jira e tool simili che mostrano il backlog come una lunga lista di item.
Vi invito a sperimentare modalità alternative che tengano conto non solo della quantità ma anche del contenuto del backlog.

Non voglio sapere semplicemente quanti item ho ma vorrei capire anche meglio come sono distribuiti sui vari contenuti.
Ricordate le categorie di cui abbiamo parlato prima? Voglio capire che tipo di gerarchia esiste tra i vari elementi, voglio avere più visibilità delle connessioni, voglio vedere la granularità. 

Qui le possibilità sono svariate: dal classico backlog analogico su parete, alla modalità story mapping, mappe mentali e mappe ad albero.
In questa presentazione potete vedere i vari spunti che ho solo raccolto alcuni spunti ma sono curiosa di capire se voi ne vedete altri o ne avete magari già utilizzato alcuni che ritenete particolarmente efficaci.