Un backlog piatto è un elenco ordinato per priorità. Ti dice cosa costruire per primo, ma non come i pezzi si incastrano insieme, e rende facile rilasciare dieci funzionalità rifinite che non compongono nulla che un utente possa completare. Una mappa di storie utente risolve questo problema disponendo le storie lungo il percorso che un utente compie, così puoi vedere l'intero prodotto e tagliare un primo rilascio che funziona dall'inizio alla fine.
Questa guida illustra come creare una story map, come trasformarne la prima porzione in uno scope MVP, come verificare ogni storia con INVEST e i pattern di suddivisione che trasformano le storie grandi in unità di dimensione sprint. Se hai bisogno delle basi, inizia con come scrivere user stories.
Cos'è una user story map
La story mapping è stata introdotta da Jeff Patton, prima in un articolo del 2005, “It's all in how you slice it”, poi nel suo post del 2008 The new user story backlog is a map, e successivamente nel suo libro User Story Mapping (O'Reilly, 2014). Vedi anche le sue risorse sulla story mapping e la voce del glossario dell'Agile Alliance.
Una mappa ha due direzioni:
- Da sinistra a destra è la narrazione: le grandi attività che l'utente compie, in ordine, e i passaggi all'interno di ciascuna. Questa riga superiore è chiamata backbone.
- Dall'alto verso il basso è priorità e dettaglio: sotto ogni passaggio si trovano le storie che lo rendono possibile, con le più essenziali in alto e alternative, casi limite e funzionalità ausiliarie in basso.
Le linee orizzontali attraverso la mappa la dividono poi in fette di rilascio. Tutto ciò che si trova sopra la prima linea è il primo rilascio; dovrebbe coprire ogni attività del backbone, anche se in modo minimale.
Come creare una story map in 6 passaggi
Puoi farlo su un muro con post-it o su una lavagna digitale. Invita le persone che decideranno lo scope e quelle che lo realizzeranno: product, design, almeno uno sviluppatore e, idealmente, qualcuno che parla con i clienti. Una prima mappa per un piccolo prodotto di solito richiede una sessione di lavoro di alcune ore.
1. Definire il problema
Scrivi per chi è il prodotto, il problema che risolve e l'esito che ti dirà se il primo rilascio ha funzionato. Tienilo a tre frasi in cima alla mappa. Ogni successiva riduzione viene giudicata rispetto a questo esito.
2. Mappare il backbone
Chiediti “cosa fa l'utente per primo, e poi cosa?” e scrivi ogni attività su una card, da sinistra a destra. Usa i verbi: “Trova un dog walker”, non “Cerca”. Poi suddividi ogni attività in passaggi. Racconta la storia ad alta voce mentre procedi; i divari diventano evidenti quando qualcuno dice “aspetta, come sono arrivato qui?”
3. Esplorare i dettagli
Sotto ogni passaggio, aggiungi le storie che lo rendono funzionante: opzioni, alternative, casi di errore, esigenze di amministrazione. Non filtrare ancora. È qui che la mappa si ripaga, perché le persone notano le parti mancanti quando possono vedere l'intero percorso in una volta.
4. Trovare lo scheletro camminante
Lo scheletro camminante (un termine di Alistair Cockburn) è la versione più sottile del prodotto che funziona da capo a fine. Scegli la storia sotto ogni passaggio che un utente non può fare a meno di avere, e spostala in alto. Se un passaggio non ha nulla di essenziale, chiediti se appartiene al backbone.
5. Tagliare i rilasci
Disegna linee orizzontali per raggruppare le storie in rilasci. Dai a ogni fetta un nome che esprima l'esito, come “I proprietari possono prenotare e pagare una passeggiata”, invece di “Rilascio 1”. Ogni fetta dovrebbe essere utilizzabile da sola e rispondere a una domanda che hai sul prodotto.
6. Pianificare la prima fetta e mantenere la mappa viva
Scrivi i criteri di accettazione per le storie nella prima fetta (il nostro modello di user story ha tre formati), verifica ciascuna con INVEST, suddividi quelle troppo grandi e spostale nello sprint backlog. Mantieni la mappa visibile e aggiornala dopo ogni rilascio; è uno strumento di pianificazione, non un output di un workshop una tantum.
Esempio: una story map per un'app di dog walking
Ecco una mappa condensata per un marketplace che collega i proprietari di cani con i dog walker locali. Le colonne sono il backbone; ogni riga è una fetta di rilascio.
| Fetta | Iscrizione | Trova un dog walker | Prenota una passeggiata | Paga | Durante la passeggiata | Dopo la passeggiata |
|---|---|---|---|---|---|---|
| Walking skeleton (MVP) | Registrati con l'email; aggiungi un cane | Visualizza un elenco di dog walker approvati vicino a un codice postale | Richiedi un orario; il dog walker accetta via email | Paga con carta al momento della prenotazione | Il dog walker segnala l'inizio e la fine della passeggiata | Il proprietario riceve un messaggio di riepilogo |
| Release 2 | Accedi con Google o Apple; più cani | Filtra per prezzo e disponibilità; profili dei dog walker con foto | Accettazione e rifiuto in-app; promemoria | Carte salvate; rimborso automatico in caso di cancellazione | Posizione in tempo reale su una mappa | Valutazioni e recensioni |
| In seguito | Codici di referral | Dog walker preferiti | Prenotazioni settimanali ricorrenti | Abbonamenti e mance | Aggiornamenti fotografici durante la passeggiata | Riprenota con un tocco |
Nota ciò che lo scheletro omette: nessun tracciamento in tempo reale, nessuna recensione, nessun messaggistica in-app e l'approvazione dei dog walker è manuale. Ma un proprietario può comunque passare dalla registrazione a una passeggiata completata e pagata, il che è sufficiente per testare se le persone prenoteranno uno sconosciuto per portare a spasso il loro cane.
Come la mappa diventa un ambito MVP
La slice superiore di una buona mappa è il tuo ambito MVP. Usa questi controlli prima di impegnarti:
- Copre ogni attività nel backbone. Un prodotto che permette alle persone di prenotare ma non di pagare non è un MVP; è metà di una demo.
- Serve un utente primario e un percorso principale. I ruoli secondari (amministratori, partner) ricevono il minimo necessario per mantenere il percorso in funzione, spesso un foglio di calcolo o un passaggio manuale.
- Testa un'ipotesi specifica. Scrivi la domanda a cui la slice risponde accanto ad essa, ad esempio “I proprietari pagheranno prima di incontrare il dog walker?”
- Il lavoro manuale dietro le quinte è consentito. Approvare i dog walker a mano o inviare riepiloghi da soli va bene per i primi utenti, e ti dice cosa vale la pena automatizzare.
- Si adatta al tuo budget e alla tua tempistica. Se non lo fa, taglia le storie all'interno di ciascuna colonna (dividendole, usando i pattern qui sotto) invece di eliminare intere colonne.
Per i fondatori senza un co-fondatore tecnico, la mappa è anche il documento più utile che puoi consegnare a un team di sviluppo: mostra l'intero prodotto, il primo rilascio e il ragionamento dietro il taglio, in una pagina. La nostra guida a costruire un MVP come fondatore non tecnico copre cosa fare con essa successivamente.
La checklist INVEST
Una volta che le storie sono sulla mappa, verifica ciascuna di esse nella prima slice contro INVEST, l'acronimo proposto da Bill Wake nel 2003 in INVEST in buone storie e task SMART.
| Lettera | Significato | Domanda da porre | Se non supera il test |
|---|---|---|---|
| I | Indipendente | Possiamo costruire e rilasciare questo senza aspettare un'altra storia? | Combina le storie strettamente accoppiate, o dividile in modo diverso affinché ciascuna si realizzi da sola |
| N | Negoziale | La soluzione è ancora aperta alla discussione? | Rimuovi i dettagli di implementazione dalla storia; tienili nelle note |
| V | Valore | Un utente o l'azienda noterebbero se questo venisse rilasciato? | Unisci i task tecnici alla storia che servono |
| E | Stimabile | Il team sa abbastanza per stimarla? | Esegui uno spike con tempo limitato, o poni le domande che bloccano la stima |
| S | Piccola | Si adatta comodamente in un unico sprint? | Dividila con uno dei pattern qui sotto |
| T | Testabile | Possiamo scrivere criteri di accettazione che passino o falliscano? | Sostituisci le parole vaghe (“veloce”, “facile”) con risultati osservabili |
L'Indipendenza è il criterio più difficile da soddisfare pienamente, ed è accettabile trattarlo come un obiettivo piuttosto che come una regola. Piccola e Testabile sono quelli su cui vale la pena essere rigorosi.
Come dividere le user story
Dividi le storie verticalmente: ogni pezzo dovrebbe comunque fornire qualcosa che l'utente può vedere, attraverso ogni livello del sistema. Dividere per livello (“costruisci il database”, “costruisci l'API”, “costruisci la schermata”) produce pezzi che non forniscono nulla finché tutti e tre non sono completati, il che vanifica lo scopo. Questi pattern, raccolti nel Humanizing Work guide to splitting user stories di Richard Lawrence e Peter Green, coprono la maggior parte dei casi.
Passi del flusso di lavoro
Dividi un processo a più fasi nelle sue fasi, oppure costruisci prima la versione end-to-end semplice e aggiungi le fasi successivamente. “Prenota una passeggiata” diventa: richiedi un orario; il passeggiatore accetta; il proprietario riceve una conferma. Successivamente: il passeggiatore propone un orario diverso.
Variazioni delle regole di business
Se una storia ha diverse regole, rilascia prima quella più comune. “Rimborsi per cancellazione” diventa: rimborso completo se cancellato 24 ore prima; rimborso parziale entro 24 ore; nessun rimborso dopo l'inizio della passeggiata.
Variazioni dei dati
Inizia con un tipo di dati e aggiungi gli altri. “Cerca per posizione” diventa: cerca per codice postale; poi per posizione attuale; poi disegnando un'area su una mappa.
Prima il percorso felice, poi i percorsi di errore
Costruisci il percorso di successo principale, poi gestisci i fallimenti come storie separate, ordinate per frequenza e per il danno che causano. “Paga con carta” diventa: pagamento riuscito; carta rifiutata; provider di pagamento non disponibile.
Operazioni
“Gestisci cani” nasconde crea, visualizza, modifica ed elimina. Spesso per il primo rilascio sono necessari solo crea e visualizza.
Variazioni di interfaccia o piattaforma
Rilascia prima su una piattaforma o con un metodo di input. Web prima di mobile, o inglese prima di altre lingue, se i tuoi primi utenti lo consentono.
Prima la versione semplice, rimanda le prestazioni
Fallo funzionare, poi fallo veloce. Un elenco di passeggiate che si carica in tre secondi per 50 passeggiate va bene per una città pilota; ottimizza quando i numeri lo giustificano, come una storia a sé stante.
Spike
Quando una storia non può essere stimata a causa di un'incognita (“possiamo ottenere la posizione live in background su entrambe le piattaforme telefoniche?”), separa una breve indagine con tempo limitato. L'output dello spike è conoscenza e una storia meglio dimensionata, non funzionalità rilasciate.
SPIDR: una versione breve da ricordare
Mike Cohn raggruppa le principali tecniche di suddivisione sotto l'acronimo SPIDR: Spikes, Paths, Interfaces, Data e Rules (Five simple but powerful ways to split user stories). Se una storia è troppo grande e non sei sicuro da dove iniziare, percorri le cinque in quell'ordine.
| Tecnica | Dividi per | Esempio |
|---|---|---|
| Spikes | Ricerca prima l'incognita | Spike di due giorni sulla posizione in background prima di stimare il tracciamento live |
| Percorsi | Percorsi alternativi attraverso la storia | Paga con carta ora; paga con wallet in seguito |
| Interfacce | Tipo di dispositivo, browser o interfaccia | Prenotazione del proprietario prima su web, poi su app mobile |
| Dati | Tipi o intervalli di dati | Un cane per prenotazione all'inizio; più cani in seguito |
| Regole | Regole di business, allentate all'inizio | Nessuna regola di cancellazione nel pilota; politica di rimborso come storia a sé stante |
Errori comuni nella story mapping
- Mappare le funzionalità invece delle attività degli utenti. Una spina dorsale di “Login, Dashboard, Settings” descrive schermate, non un percorso.
- Costruire la prima fetta con una sola colonna di profondità. Perfezionare la registrazione prima che esista la prenotazione ti lascia senza nulla da testare.
- Lasciare che la mappa diventi troppo dettagliata. Se stai scrivendo i criteri di accettazione sul muro, sei passato dalla mappatura al raffinamento.
- Mappare senza gli sviluppatori in sala. Le fette tracciate senza di loro spesso nascondono storie costose in cima.
- Trattare la mappa come finita. Dopo ogni rilascio, trasferisci ciò che hai imparato sulla mappa e ricompila la prossima fetta.
Per storie ben formate che puoi adattare alla tua mappa, consulta il nostro esempi di user story.
Strumenti per la story mapping
Un muro e post-it funzionano ancora meglio per la prima sessione con tutti in una stanza. Per le team remote, lavagne bianche generali come Miro e FigJam hanno template di story map, e strumenti dedicati come StoriesOnBoard sincronizzano le mappe con i tracker di backlog. Jira e tracker simili possono mostrare le storie raggruppate per epica, il che ti dà la spina dorsale, ma di solito hai bisogno di un plugin o di una lavagna per vedere le fette di rilascio. Scegli lo strumento che la tua team manterrà aperto; una mappa che nessuno aggiorna smette di essere utile entro uno o due sprint.
Domande frequenti
Cos'è la user story mapping?
Una tecnica, introdotta da Jeff Patton, per disporre le user story lungo il percorso che un utente compie (la spina dorsale, da sinistra a destra) e per priorità (dall'alto in basso). Le linee orizzontali dividono la mappa in fette di rilascio, in modo che la team possa pianificare rilasci che funzionano da capo a fine.
Qual è la differenza tra una story map e un product backlog?
Un backlog è un elenco singolo ordinato per priorità. Una story map mostra le stesse storie in due dimensioni, per attività utente e per priorità, in modo da poter vedere come si incastrano tra loro e se un rilascio copre l'intero percorso.
Cos'è uno walking skeleton?
La versione più sottile di un prodotto che funziona dall'inizio alla fine, con una storia essenziale sotto ogni passo del percorso. Il termine proviene da Alistair Cockburn; su una story map è di solito la prima fetta di rilascio.
Cosa significa INVEST?
Indipendente, Negoziabile, Valore, Stimabile, Piccolo e Testabile. Bill Wake lo ha proposto nel 2003 come un elenco di controllo per buone user story.
Quanto dovrebbe essere piccola una user story?
Basta piccola perché la team possa completarla, testarla e dimostrarla entro uno sprint, e idealmente entro pochi giorni. Se una storia richiede regolarmente un intero sprint, dividila.
Cos'è SPIDR?
Un insieme di cinque tecniche di suddivisione delle storie descritte da Mike Cohn: Spikes, Paths, Interfaces, Data e Rules.
Chi dovrebbe partecipare a una sessione di story mapping?
Le persone che decidono lo scope e le persone che lo costruiranno: product owner o fondatore, designer, almeno uno sviluppatore e, idealmente, qualcuno che parla con i clienti, come supporto o vendite.
Hai una mappa, o solo un'idea, e hai bisogno di costruire la prima fetta? Possiamo aiutarti a definire lo scope di un MVP che funziona da capo a fine e a rilasciarlo in sprint brevi. Vedi i nostri piani di sviluppo mensili.