Dopo aver parlato di visione e aver presentato gli strumenti Lean Canvas e Vision Board, parliamo in questo articolo di User Story Mapping, uno strumento che ci consente di definire l’elenco delle cose da fare e di preparare la strada alla costruzione del Product Backlog Items, altro manufatto fondamentale nell’ambito delle metodologie agili e in particolare di Scrum.
Intro
Una celebre frase di Kent Beck recita: “le roadmap dei prodotti dovrebbero essere liste di domande e non elenchi di funzionalità”. In quest’ottica, questo mese intendiamo parlare delle tecniche per arrivare a definire l’elenco delle cose da fare. In Scrum si parla in questo caso di Product Backlog Items. Per arrivare a una prima versione del PBI, è necessario individuare la lista delle funzionalità del sistema e trovare anche un ordine con cui metterle in fila. Fra le varie tecniche che si possono utilizzare, quella delle User Story Mapping è una delle più efficaci e sta diventando famosa proprio per questo motivo.
Difetti e limiti di una “to-do list” monodimensionale
Uno degli strumenti più importanti di Scrum, ma utilizzato anche in altri contesti, è il Product Backlog, una pila che contiene l’elenco delle cose da realizzare all’interno del progetto. Ogni elemento di questa pila rappresenta un preciso bisogno dell’utente che utilizzerà il prodotto che si sta realizzando. Nella maggior parte dei casi gli elementi sono descritti col formalismo delle storie utente ma si possono usare anche altri formati.
Definire la struttura del backlog
Nella parte alta di questa pila ci sono le storie ad alta priorità, quelle che si ritiene sia più utile implementare per prime perchè la loro implementazione fornisce all’utente un valore maggiore; nella parte bassa invece ci sono quelle funzionalità che sono spesso considerate “nice to have” ossia aggiunte utili al prodotto, ma non indispensabili per l’utilizzo.
Una mappa bidimensionale
In questa puntata parleremo di Story Mapping una tecnica particolarmente utile perchè, tramite un lavoro di gruppo, una sorta di discussione collaborativa, permette di arrivare non solo alla definizione del contenuto del Product Backlog, ma anche alla realizzazione di una mappa delle cose da fare, mappa che rappresenta un valido strumento complementare o in sostituzione del Backlog; in questo senso rappresentano degli information radiators, cioè degli strumenti per “irraggiare informazioni” probabilmente più efficaci del backlog, con i quali visualizzare e comunicare lo stato di avanzamento delle cose, nonchè i contenuti delle lavorazioni: sono una sorta di schema bidimensionale che sta riscuotendo un buon successo proprio grazie all’aggiunta di una seconda dimensione, che permette di avere una visione d’insieme spesso migliore di quella offerta dalla lista monodimensionale del backlog.
Avere a disposizione una visione bidimensionale del lavoro da svolgere agevola inoltre le attività di valutazione, prioritarizzazione e raffinamento delle storie. Grazie alla sua immediata capacità di fornire una rappresentazione visuale delle cose da fare, la Story Map definisce una sorta di linguaggio universale facilmente comprensibile anche da persone non facenti parte dello staff agile.
Il processo stesso di creazione e di gestione della mappa agevola la discussione collaborativa del gruppo; la tecnica di lavoro, iterativa e incrementale, si basa su un procedimento semplice e comprensibile anche da personale non tecnico o che non sia stato introdotto alle pratiche agili: per questo spesso viene utilizzata come strumento alternativo nelle sessioni di project planning tradizionale, dove sia necessario chiarire gli aspetti legati alle scadenze, alle tempistiche e allo scope delle varie release di progetto/prodotto.
Come nascono le Story Maps: le considerazioni di Jeff Patton
Anche se le story maps sono utilizzate da molto tempo in varie forme, il primo che probabilmente le ha formalizzate e rese famose è stato Jeff Patton, che l’ha descritta nel suo libro “User Story Mapping” [USM]. Fra le molte caratteristiche che secondo Patton rendono importanti le mappe, è la loro capacità di offrire una rappresentazione persistente del lavoro di visioning nonchè del contesto di lavoro. Nel suo libro infatti Patton racconta:
“Trascorriamo molto tempo a lavorare con i nostri clienti e ci sforziamo di comprendere i loro obiettivi, i loro utenti e le parti principali del sistema che potremmo costruire. Infine arriviamo ai dettagli: le diverse parti delle funzionalità che ci piacerebbe costruire. Io immagino questo processo come se fosse un albero: il tronco è costituito dagli obiettivi o dai vantaggi desiderati per cui si decide di costruire il sistema; i rami grandi principali rappresentano gli utenti; i rami secondari più piccoli sono le capacità di cui essi hanno bisogno; e, infine, le foglie sono le storie utente, sufficientemente piccole da poter essere impiegate nelle iterazioni di sviluppo.
Dopo tutto questo lavoro, in cui si è creata tutta questa conoscenza condivisa, a me sembra che spesso si comincino a staccare le foglie dell’albero e a buttarle nei sacchi per lo smaltimento, e poi si proceda ad abbattere l’albero. Ecco come mi appare un backlog piatto: un sacco di pacciame senza un contesto […]
Le storie davvero grosse possono essere considerate come delle ‘epiche’: Mike Cohn le descrive per l’appunto in questo modo. Sono storie, solo che si tratta di storie veramente grandi: troppo grandi per essere valutate e sviluppate. Quando un’epica entra nel nostro backlog e arriva il momento di discuterla nel dettaglio, vedo spesso le persone che la rimuovono dal backlog stesso, la scompongono e sostituiscono i pezzi che riescono a identificare. Questa è la classica situazione in cui non posso trattenere una smorfia quasi di dolore: è esattamente il caso dell’abbattimento dell’albero del quale si mantengono le foglie dentro un sacco per il pacciame. Infatti, quella storia grande costituiva comunque il contesto. Era il mio modo semplice di pensare a riguardo dell’intera attività che le persone stavano svolgendo; era il mio modo veloce di spiegare agli altri come vedo io il sistema”.
A riprova che la User Story Mapping non è una tecnica inventata da Jeff Patton, c’è la stessa testimonianza dell’autore che racconta come spesso trovasse presso i clienti tecniche analoghe o del tutto simili. In questo senso Patton ci dice quindi che la Story Mapping non è una tecnica, ma piuttosto un pattern di lavoro:
“Se si spiega un concetto e si riceve come risposta ‘Che bella idea!’, non siamo di fronte a un pattern. Ma se le persone ci dicono ‘anche noi usiamo qualcosa di simile a questo strumento’, allora siamo in presenza di un pattern”.
Story Map Workshop, il processo per arrivare alla mappa delle storie
In questo articolo vediamo come si può arrivare alla definizione della mappa delle storie tramite un processo detto di Story Map Workshop: partendo dal lavoro descritto dallo steso Jeff Patton nel suo libro, aggiungeremo alcune tecniche o variazioni che abbiamo trovato utili nel corso delle attività di coaching in progetti agili. In particolare l’applicazione della tecnica del buy an issue per la valutazione del valore delle cose da fare è il stata da me introdotta (e siete quindi liberi di considerarla una stupidaggine) prendendo spunto da tecniche di Value Stream Mapping e serious gaming viste in azione l’anno passato alla conferenza Play14 (si veda a tal proposito [PLAY14], al paragrafo intitolato “A tasty cupcase”).
In perfetto stile agile, la realizzazione della mappa viene fatta dalle stesse persone che poi effettueranno la lavorazione del progetto: essenziale la presenza del Product Owner (o figura analoga se il progetto non sarà organizzato secondo Scrum), di qualche membro del team di sviluppo (in questo momento non è necessario che ci siano tutti, ed essere in pochi può risultare un buon modo per mantenere un clima intimo e riflessivo) e di altri stakeholders interessati allo sviluppo del prodotto. In questa prima fase non è essenziale che partecipi il team di sviluppo al gran completo. Ovviamente è necessario che ci sia un facilitatore, un coach che guidi la riunione, scandisca i tempi e definisca le attività.
Elenco degli utenti del sistema
Per identificare un primo elenco con le macrofunzionalità del sistema, si cambia il punto di vista, guardando il sistema dal punto di vista degli utenti e immaginando quindi quali saranno le attività che essi possono o desiderano svolgere all’interno del prodotto.
Per prima cosa quindi il gruppo di lavoro procede nell’individuare l’elenco degli utenti del sistema: questo lavoro può essere fatto in modo collaborativo (tutti di fronte alla lavagna) oppure isolatamente, tramite la tecnica del silent brainstorming, tecnica di collaborazione basata sull’uso di cartoncini attaccati alla parete. La tecnica del silent brainstorming è descritta i modo piuttosto chiaro presso [SB]: in sintesi, potremmo dire che si tratta di una modalità di lavoro in cui ogni membro del team per prima cosa stila, lavorando individualmente e in silenzio, un proprio elenco di risposte o proposte. Successivamente ogni elenco personale verrà presentato agli altri, discusso e confrontato.
Non sempre è possibile nè semplice procedere in questo modo e quindi si preferisce partire definendo l’elenco delle classi di utenti dell’applicazione: una tecnica molto utile in questo caso è certamente quella della definizione delle Personas, di cui si è avuto modo di parlare sia in alcuni articoli pubblicati su MokaByte [UX] dedicati allo sviluppo dell’esperienza utente, che in una puntata precedente di questa serie [VIS].
L’obiettivo di questa fase è quello di arrivare con un elenco di nomi di ruoli o personas scritti ognuno su un cartellino e attaccati nella parte alta della parete o lavagna, come riportato nella figura 2.
Le attività svolte dagli attori
Dopo aver individuato gli utenti del sistema, si procede a individuare le azioni che ognuno svolge all’interno dell’applicazione. Anche in questo caso si può lavorare in modalità silent brainstorming, in modo che ognuno scriva su dei biglietti un elenco di funzionalità: ogni bigliettino dovrebbe esprimere una azione precisa, quindi iniziare con un verbo e concludersi eventualmente con un complemento oggetto; per esempio: “creare nuovo utente“, “inviare mail“, “stampare report” e così via.
Per questa fase si sceglie lo stesso colore dei biglietti adesivi per tutti i partecipanti, scrivendo un’attività per biglietto: questa fase deve durare pochi minuti, ma il facilitatore, in base a segnali non verbali delle persone, può intuire se il gruppo termina prima o se è necessario ulteriore tempo.
Al termine della compilazione dei biglietti, ogni persona presenta i propri cartellini uno per uno attaccandoli alla lavagna sotto l’utente corrispondente.
Ogni cartellino può rappresentare una procedura, un processo o un indicare una precisa esperienza utente nel sistema: per questo i cartellini a volte prendono il nome di “viaggio” (User Journeys). Secondo la terminologia introdotta da Patton, queste attività prendono il nome di User Tasks.
Un accorgimento in più: la linea temporale
A mano a mano che tutti attaccano i propri cartellini, può essere utile che ogni persona disponga i propri in una sorta di corsia orizzontale cercando per quanto possibile di considerare la dimensione orizzontale come una sorta di linea temporale relativa alle operazioni che l’utente svolge all’interno del sistema (figura 3). Questa è una opzione che non si trova nel libro di Patton, ma è stata utilizzata personalmente da me e da altri facilitatori sui team dove si riteneva ci fossero molti punti ancora da chiarire fra le persone.
In questa fase le attività sono ancora organizzate in colonne corrispondenti ai vari utenti, per cui è necessaria una razionalizzazione per rendere più utile questa raccolta: se da un lato sono possibili duplicati (per esempio due utenti differenti potrebbero entrambi dover effettuare delle attività di stampa o di ricerca), dall’altro è più utile per passare alla fase di implementazione, organizzare i task per macroarea funzionale.
Per questo si tolgono in testa alle colonne i cartellini con gli utenti e si procede a una riorganizzazione dei vari cartellini spostandoli da destra a sinistra in modo da raggruppare quelli che corrispondono ad attività simili. In questo momento si eliminano i duplicati: in caso di dubbi sull’eliminazione di cartellini simili o sul posizionamento di casi dubbi, si potrà rimandare a dopo ogni ulteriore approfondimento.
Attività utenti e colonna portante
Al termine di questo lavoro, ogni colonna formata dovrebbe rappresentare una macroarea funzionale del prodotto che si va a realizzare: ad ogni colonna si assegna quindi un nome che sia espressione delle funzionalità. Queste macro aree funzionali sono quelle che Jeff Patton chiama User Activities: l’insieme delle attività da luogo alla Backbone dell’applicazione. Patton, che fa un largo uso di metafore anatomiche, con il termine Backbone non vuole far riferimento solamente alla classica metafora con cui indicare “la colonna portante dell’applicazione”, ma pensa invece proprio una specie di struttura ossea composta da vertebre (le attività) che se disegnata in orizzontale vedrà agganciate in verticale le varie costole (i task o storie utente come avremo modo di vedere fra poco).
Durante l’attività di raggruppamento per identificare le User Activities, si consiglia di disporre i vari cartellini nella parte alta della board a formare, se possibile, un’unica riga che rappresenta la raccolta di funzionalità ad alto livello, che verranno chiamate User Tasks (un’altra parola presa in prestito dalla teoria della UX).
Jeff Patton in questo caso dice che: “Per molte delle persone che impiegano metodologie agili, ‘task’ fa riferimento ai compiti che gli sviluppatori devono svolgere per portare a compimento le storie utente. Ma in realtà, un ‘task’ è qualcosa che qualcuno fa per raggiungere un obiettivo. Un ‘task utente’ sono le azioni svolte da un utente per raggiungere il suo obiettivo, mentre i ‘task degli sviluppatori’ sono le azioni che gli sviluppatori devono compiere per creare le storie.”
La disposizione dei task all’interno della loro riga deve essere fatta in modo da raggruppare in colonne i biglietti corrispondenti a macrofunzionalità simili fra loro.
Una visione comune sul valore delle attività
A questo punto, potrebbe essere utile analizzare se le varie persone (in particolare il PO vs. il resto del team) hanno una visione comune circa l’importanza o il valore delle varie attività. Per fare questa valutazione, oltre a stimolare una discussione libera, si può utilizzare una tecnica presa in prestito dal Value Stream Mapping, che a volte viene presentata in forma di gioco dal nome Buy An Issue.
Supponendo di dare dei soldi virtuali ai partecipanti (potrebbero essere 100 € o 100 $ o semplicemente 100 punti) si chiede a ciascuna persona di disporre i questi soldi sulle varie attività in funzione del valore, dell’utilità o genericamente del ROI (indice di redditività) che ci si attende dall’implementazione di tale funzione.
Nella figura 5 è riportato il risultato ottenuto utilizzando per votare dei biglietti colorati: in questo caso ogni persona riceve un numero prefissato di biglietti che usa come gettoni o fiches per votare; la votazione avviene semplicemente attaccando i vari biglietti ai task che si ritiene siano di maggior valore. Al termine della votazione, analizzando la disposizione dei biglietti o la macchia di colore, si può dedurre in modo estremamente semplice ma efficace, quali sono i task il cui valore è ritenuto più elevato.
Una variante del gioco si ottiene utilizzando un punteggio totale uguale per tutti (p.e.: 100 punti) che le persone assegnano scrivendo su cartoncini il punteggio che pensano sia da abbinare ad ogni storia.
Dopo che il team ha discusso sulle varie differenze sui punteggi, si può quindi provare a unire le varie soluzioni, accorpando, sostituendo, cambiando.
Unificare la linea di attività
Il passo successivo è giungere a una unificazione delle varie swimlane, in modo da arrivare ad avere una sola linea di attività. Se lo si desidera, si potranno mantenere i punteggi sulla swimlane finale: al team la decisione se usare la media aritmetica, la media pesata o altro ancora.
Prioritarizzazione dei task
Il passo successivo è quello di introdurre la dimensione temporale rispetto alla quale il gruppo implementerà le funzionalità del sistema. In tal caso ha certamente poco senso ordinare le colonne con le User Activities, visto che queste sono funzionalità di alto livello delle quali tutte conterranno al loro interno alcune parti più urgenti insieme ad altre che potranno essere realizzate in un secondo momento.
Riprendendo l’esempio portato da Jeff Patton nel suo libro, si potrebbe immaginare un progetto che debba ideare, disegnare e poi costruire un’automobile. In questo caso le varie macrofunzionalità potrebbero essere le User Activities (“impianto frenante”, “sistema di propulsione”, “impianto sterzante”, “carrozzeria”, “struttura portante” etc.). In questo caso è veramente difficile, se non inutile, utilizzare del tempo per capire se sia più importante la activity impianto frenante o quella relativa al motore o alle ruote. Dette in questo modo, sono tutte importanti e non è possibile stabilire in alcun modo a cosa convenga dare priorità: un’eventuale implementazione minimum viable product (MVP) di automobile che includa solo una o l’altra sarebbe comunque inutile se non addirittura pericolosa.
Priorità dei sottocomponenti
Entrando invece nel dettaglio delle varie Activity è evidente come sia possibile optare per una qualche forma di prioritarizzazione basata sull’importanza dei sotto-task: per esempio, dell’impianto frenante potremmo rimandare a un secondo momento l’implementazione di un sistema di antibloccaggio delle ruote; l’ABS è importante ma può essere considerato un meccanismo da introdurre in un secondo momento, certamente dopo che si sia realizzato il prototipo da far vedere agli utenti finali. Discorso analogo per la carrozzeria o per il motore: ci sono molte parti e funzionalità che potrebbero essere inserite in un secondo momento, dopo la realizzazione del prototipo.
Tornando alla mappa che si sta realizzando, si può quindi introdurre un asse verticale sul quale spostare i vari task in base all’urgenza con la quale si vorranno implementare. Questa attività di ordinamento è ovviamente in carico al Product Owner, anche se potrà essere aiutato da altre persone; è comunque sua la responsabilità ultima dell’ordine delle cose da fare.
La prima riga: MVP
A questo punto, osservando la prima riga che si forma in alto vicino alla linea della backbone, si potrà constatare che essa contiene le storie che possono dar vita a una versione minimale dell’applicazione con tutte le funzionalità essenziali per gli utenti finali. La prima riga rappresenta quindi la versione Minimum Viable Product (MVP) del prodotto: prendendo in prestito una definizione di Alistair Cockburn, è detta Walking Skeleton, con una immagine molto eloquente di uno scheletro (quindi solo la struttura portante) in grado comunque di camminare (quindi di svolgere alcune funzioni fondamentali). Sul sito di Cockburn si trova questa interessante definizione: “[il walking skeleton] è una implementazione minimale del sistema in grado di svolgere una piccola funzione end-to-end. Non necessita di usare l’architettura finale, ma dovrebbe collegare insieme i principali componenti architetturali. La parte architetturale e la parte funzionale possono poi evolvere in parallelo” [WS].
Release
Dopo aver individuato la priorità circa l’implementazione dei vari task, grazie all’introduzione della dimensione temporale, si può raffinare questa suddivisione introducendo il concetto di release, disegnando delle strisce in orizzontale (figura 9).
Conclusioni
La User Story Map è uno strumento molto utile e versatile che richiede alcune conoscenze e un po’ di pratica, ma che risulta molto chiaro e capace di irradiare conoscenza a chi lo utilizzi. Consente una definizione collaborativa dei vari task, una loro organizzazione in macroaree funzionali, una prioritarizzazione in termini di valore delle varie attività e di tempi di realizzazione delle varie funzioni.
Insieme agli altri strumenti visuali analizzati negli articoli precedenti, la User Story Map contribuisce in maniera strutturata ma flessibile ad affrontare il percorso che porta dalla visione al prodotto finale.