Story Mapping: visualizza il tuo prodotto

Se ti interessi di metodologie agili avrai sicuramente sentito parlare di Story Mapping, una tecnica molto semplice ma allo stesso tempo efficace che ci consente di organizzare e tenere assieme in maniera visuale ogni componente del nostro product backlog.

Lavorando con il product backlog, infatti, capita spesso di trovarsi di fronte a una giungla di “work item” che magari hanno senso nel momento in cui si scrivono, ma se accumulati in modo scriteriato, a lungo andare, ci fanno perdere  la visione d’insieme. Per work item si intende una user story, o una sezione di essa, che svolge una determinata e caratteristica funzione.

La giungla dei componenti

In ambiti complessi o altamente tecnici, forse ti è già capitato di trovare sparpagliati nel backlog questi oggetti non meglio identificati: bottoni, griglie, filtri per tabelle, chiamate a servizi e componenti architetturali varie. Oggetti che non hanno necessariamente valore di business ma che indubbiamente ci servono per sviluppare il nostro prodotto. 

Il problema è che di fronte a uno spettacolo di questo tipo, non tutti coloro che hanno accesso al product backlog sono in grado di ricomporre il puzzle; a volte neanche il Product Owner! C’è dunque il rischio di andare a ritroso e costruire il nostro prodotto e la nostra proposta di valore artificiosamente, a partire da queste singole componenti software, perdendo d’occhio il “che cosa” e magari anche il “perché”.

Qual è la soluzione? Un buon consiglio è cercare di creare questi work item in maniera più verticale possibile, partendo dall’alto (il processo e gli attori coinvolti), per poi dirigersi verso il basso (le singole componenti di un prodotto). Story Mapping può aiutarci nel compito di mantenere il percorso dell’utente al centro della nostra azione, senza perdere di vista queste famose componenti software ma mettendole al servizio del problema che dobbiamo risolvere.

Cos’è Story Mapping

Secondo Agile Alliance, il concetto di Story Mapping è stato formulato da Jeff Patton per la prima volta nel 2005 nell’articolo “It’s All in How You Slice It” e in seguito, nel 2008, in “The new user story backlog is a map”.

Story mapping è un ottimo strumento di collaborazione, sia all’interno del team di sviluppo sia come mezzo di comunicazione con i clienti e gli stakeholder. Il risultato finale è la produzione una mappa delle user story contenute nel product backlog che dà una visione di insieme sull’interazione dell’utente con il prodotto (user journey), i casi d’uso, la proposta di valore e le priorità. 

Questa mappa è un documento in continua evoluzione va mantenuto aggiornato man mano che si procede con lo sviluppo e il rilascio del prodotto.

Come iniziare con Story Mapping

Prepara dei foglietti adesivi post-it di dimensioni rettangolari, di tre colori diversi (per esempio: blu, rosa, giallo).

Prima di iniziare con la mappatura, ti suggerisco di identificare chi è la nostra persona o la tipologia di utente di riferimento. Può essere una buona idea scriverlo su un foglietto adesivo, per esempio quello blu, sotto forma di user story. Ma non è obbligatorio, sei libero di decidere tu la forma più ottimale.

La mappa delle user story è composta da due assi:

  • asse orizzontale (post-it rosa): questa dimensione rappresenta il “workflow”, ovvero l’interazione dell’utente con il nostro prodotto
  • asse verticale (post-it giallo): qui vengono mappate le attività (ma anche le componenti software, se necessario) con il corrispettivo step del workflow. Tipicamente, un’attività, corrisponde a una user story del nostro product backlog

È una buona idea utilizzare una parete dell’ufficio per Story Mapping, anche se esistono diversi tool online che sono semplici da utilizzare e consentono di collaborare anche da remoto.

story mapping
Clicca per ingrandire

Esempio di Story Mapping

Credo che un esempio pratico sia più efficace di mille parole. Facciamo finta di essere il Product Owner del team di sviluppo di un’agenzia di viaggi. Oggi vogliamo mappare, insieme al team e ad alcuni stakeholder, l’interazione dell’utente con il nostro catalogo online. Ovviamente, qui semplificheremo.
Partiamo con la persona e il “cosa”. Foglietto blu alla mano.


Anna: voglio comprare un pacchetto dal sito di viaggi

Ora possiamo identificare gli step per scegliere e acquistare il pacchetto di viaggio. Li scriveremo sui foglietti rosa e li disporremo sull’asse orizzontale. Gli step potrebbero essere: cerca pacchetto di viaggio, visualizza pacchetto, seleziona pacchetto, sign up, acquista pacchetto, ricevi informazioni viaggio.

Per ogni foglietto rosa, dovremo identificare un’azione – armati di foglietti gialli.

Per cerca pacchetto di viaggio, mi viene in mente:

  • sfoglia catalogo
  • ricerca semplice
  • ricerca avanzata

Per visualizza pacchetto:

  • visualizza dettagli pacchetto
  • confronta due o più pacchetti

In seleziona pacchetto:

  • aggiungi al carrello
  • salva tra i preferiti

Sign up potrebbe includere:

  • login via email
  • login via social media

In acquista pacchetto:

  • ordina
  • integrazione con sistema di booking voli
  • paga con bonifico
  • paga con carta di credito
  • integrazione con software gestionale

E infine, ricevi informazioni di viaggio:

  • invia biglietto via email
  • iscrizione alla newsletter
  • invia offerte correlate via email

Se preferisci, ciascuna azione può essere espressa sotto forma di user story.

Assegnare le priorità

Oltre ad esprimere le attività, l’asse verticale riflette anche quelle che sono le priorità. Volendo potresti delimitare con linee orizzontali ciascun rilascio o incremento, in modo da dare visibilità sul “quando” determinate funzionalità saranno rese disponibili. Nell’immagine al centro di questa pagina, per esempio, ho identificato due versioni: 20.01 e 20.02.

Ogni partecipante può suggerire azioni da includere nel workflow e il Product Owner potrà, in un secondo momento, riordinare i foglietti gialli in base al valore di business e assegnarli a determinati rilasci, in base alle informazioni sulla dimensione delle attività e la capacità del proprio team. Poi potrà validare il tutto durante lo Sprint planning ed aggiornare le priorità sulla mappa.

Immagina anche i vantaggi di questa tecnica, se reiterata durante gli Sprint review meeting: grazie all’impatto visivo, sarà molto più semplice comunicare le previsioni, le aspettative e il progresso agli stakeholder e al team. 

Chi partecipa

L’evento di Story Mapping dovrebbe coinvolgere un gruppo diversificato di persone. Oltre agli sviluppatori, che hanno competenze tecniche, sarebbe utile includere anche persone con esperienza in materia (nell’esempio qui sopra, magari alcuni agenti di viaggio), stakeholder interni o esterni, UX designer e Product Owner.

Per poter eseguire Story Mapping in maniera efficace, in tutto dovrebbero partecipare tra le 4 e le 8 persone. Con un tal numero di persone, tutti hanno la possibilità di esprimersi.

È importante sottolineare che un po’ di discussione tecnica non guasta, ma non dovrebbe essere centrale in questo tipo di esercizio. L’obiettivo infatti è identificare il “che cosa”, e magari anche il “perché”, ma non il “come”. Il risultato dovrebbe essere una mappa che può essere condivisa all’interno dell’organizzazione e di facile accesso anche per i non addetti ai lavori.

Conclusione

Come abbiamo visto in precedenza, Story Mapping è un utile strumento di comunicazione che può essere utilizzato per dare visibilità sia al team di sviluppo sia agli stakeholder. Per questo motivo non dà dettagli su “come” risolvere un determinato problema, ma si limita a illustrare la user journey, le funzionalità del nostro prodotto e le priorità.

È una versione più accessibile del product backlog, che spesso è di difficile lettura e non dà visibilità dei risultati che si vogliono conseguire.

Esattamente come il product backlog, la mappatura deve essere tenuta aggiornata nel corso del tempo, riflettendo lo stato corrente dello sviluppo. Non è quindi sufficiente fare Story Mapping una volta l’anno, come se fosse una “roadmap”, dato che perderesti alcuni dei vantaggi illustrati qui sopra.

Una volta identificate le attività (i foglietti gialli), il mio suggerimento è di inserire le user story in un sistema tipo Jira e utilizzare l’ID generato dal sistema come collegamento tra il foglietto post-it il software di tracciamento. Volendo potresti anche raggruppare o taggare le user story che hai inserito nel sistema utilizzando come guida i foglietti post-it rosa (gli step).

Puoi attaccare i foglietti adesivi che hai prodotto con Story Mapping in un muro adiacente all’area dove siede il team Scrum, o fare affidamento su software di terze parti. L’importante è dare visibilità, in modo che i progressi siano visibili a tutti. E grazie a Story Mapping, comprensibili alla maggior parte.

Lettura consigliata


libro story mapping
Jeff Patton

User Story Mapping: Discover the Whole Story, Build the Right Product

Formati: Kindle e Copertina flessibile, 324 pagine
Editore: O’Reilly Media
Lingua: Inglese