Dalla vision al Backlog con la Vision Board

Come si procede dalla vision iniziale alla formulazione delle singole user stories?
Quali sono i passi da seguire?

Venerdì 14 marzo si è tenuto al Politecnico di Milano una conferenza dal titolo “Agile for Innovation” aperta da uno speech di Roman Pichler sulla strategia agile di prodotto.

Il primo consiglio di Pichler è di non saltare subito all’esecuzione, bensì dedicare tempo alla formulazione di una strategia, a definire il percorso verso gli obiettivi prefissati.
Abbiamo una vision, una “big picture”, un’idea sfidante che è la nostra meta.
A questo punto è importante rispondere ad alcune domande fondamentali per elaborare la strategia: chi, perché, cosa, qual è il risultato atteso?

Proviamo a chiederci:

Chi sono gli utenti?
Ma anche chi sono i clienti, ovvero coloro che pagheranno per il nostro prodotto (non è detto che chi paga coincida sempre con l’utilizzatore finale…).

Per quale motivo potrebbero essere interessati ad usare il  prodotto? 

Perché dovrebbero comprarlo?

Che cosa rende unico il prodotto? 

Esploriamo la value proposition….
Quali sono le sue caratteristiche chiave?
E’ importante rimanere ad alto livello in questa fase; definiamo 3 key features, massimo 5.

Quali sono gli obiettivi di business? 

Per quale motivo dovremmo investire in questo progetto i nostri soldi invece che in altro?

Per guidarci nella risposta a questi quesiti Pichler ha elaborato un tool semplice e potente che può essere applicato in svariati ambiti:
la Vision Board.

E’ un foglio A4 che contiene una tabella divisa in 5 aree:
– la vision
– il target
– i bisogni che il prodotto soddisfa
– le caratteristiche chiave del prodotto
– gli obiettivi di business

Una volta che la strategia è delineata siamo pronti a partire?
Non ancora!
La vision board traduce l’idea iniziale in una strategia, ma prima di arrivare al backlog e alle singole user stories è opportuno prevedere una fase di test.
La strategia contiene indubbiamente delle ipotesi.
Fate un esame di quali sono le principali assunzioni che avete fatto ed elencate i possibili rischi. Metteteli in ordine di priorità (per esempio in base alla gravità dell’effetto che possono produrre) e procedete con interviste ad utenti e clienti.

Il vero lavoro è questo: non implementare il prodotto, ma testarne il prima possibile le idee e le assunzioni (un punto di vista molto simile a quello di Eric Ries…).
In questo modo la strategia non è scolpita per sempre nella pietra, ma emerge e si arricchisce in base ai feedback degli utenti.

… e se proprio doveste accorgervi di essere fuori strada, potete sempre cambiare rotta o abortire del tutto il progetto con perdite assai contenute (comunque ben prima della fase più costosa, lo sviluppo!)

Il potere di dire no

Quando un Product Owner può definirsi veramente tale?

Pichler sostiene ci sia un test semplicissimo per capire se una persona sta ricoprendo davvero il ruolo di Product Owner.
Basta porre la fatidica domanda “Hai il diritto di dire no?

Quando dire NO
Ci troviamo a dire no in tante diverse situazioni.
Non si tratta di un’attitudine negativa nei confronti del mondo o del lavoro da fare. 
Ci sono occasioni in cui i no fanno la differenza tra il successo ed il fallimento di un progetto.

Diciamo no quando una richiesta non è allineata con gli obiettivi che stiamo perseguendo, diciamo no quando un desiderata non porta reale beneficio all’utente o quando il valore di una richiesta non è in alcun modo misurabile o testabile.

Diciamo no quando i desiderata vengono dalla pancia ma non sono argomentati né analizzati alla luce di dati reali.

Soprattutto diciamo no quando ciò che ci viene richiesto non è indispensabile per l’esito positivo del progetto. Perché tutti noi combattiamo con risorse scarse (siano esse tempi, costi o persone) ed il nostro primo pensiero è rimanere focalizzati su ciò che è davvero essenziale per la riuscita di un prodotto o un servizio escludendo ciò che è “rumore di fondo”.
Più funzionalità difficilmente sono sinonimo di prodotto migliore, se mai più complesso…

Dire NO è un esercizio difficile
Diciamocelo: il Product Owner non è un mestiere per cuori teneri o per persone alla ricerca di conferme…
Non è mai bello dire di no e “fare la parte del cattivo”, ma se non siamo in grado di farlo perché per indole vogliamo compiacere i nostri interlocutori questo ruolo non fa per noi.

Ovviamente riuscire a dire no nel modo giusto richiede pratica e dedizione. C’è modo e modo di farlo!
Dobbiamo riuscire a far comprendere che l’accettazione o il rifiuto di un desiderata non è mai una questione personale, bensì una scelta ragionata per la soddisfazione dei nostri utenti.
Siamo disponibili ad ascoltare tutte le richieste, ne analizziamo la portata e il contesto però quando si rivelano incoerenti con la strategia o la roadmap gentilmente e con fermezza diciamo no argomentandone le motivazioni.

Quando dire NO è ancora più complicato
Come si suol dire “qui casca l’asino”…
Diciamo che avete raggiunto un buon grado di confidenza nel vestire i panni del Product Owner ed avete instaurato un rapporto di fiducia con il team e lo Scrum Master.
Avete anche gentilmente rimandato al mittente alcune richieste minori provenienti dagli utenti o da colleghi della vostra stessa azienda.
Che succede però quando le richieste arrivano dall’alto?
Siete in grado di dire no anche all’amministratore delegato? Al direttore vendite? In generale a tutti quegli stakeholder che potrebbero influire sulla qualità della vostra vita professionale?

Anche in questo caso se il desiderata è campato in aria, non ha alcuna attinenza con quanto state facendo o pensate possa essere addirittura controproducente dovreste dire no.
Più facile a dirsi che a farsi, lo so.
Ma vi invito quantomeno a non arrendervi a priori. Chiedete, fate domande e argomentate la vostra posizione. Potreste scoprire di non avere elementi validi per ribattere o di non avere tutte le informazioni chiave per prendere una decisione… oppure potreste fare breccia nelle idee del capo grazie ai vostri dati alla mano.
In ogni caso vale la pena tentare e ritentare.

Quando manca la delega
Infine, un punto dolente in molte realtà lavorative (quantomeno – nella mia modestissima esperienza – in quelle italiane).
C’è una situazione peggiore rispetto a quella di non sapere o non potere dire no.
E’ quando il no o il sì del Product Owner contano poco nulla.
Se non c’è sponsorship da parte del management, se le decisioni del PO vengono regolarmente contraddette da persone “più alte in grado”, se non vengono condivise le informazioni utili per decidere, se non si ha insomma “licenza di uccidere” (si fa per dire…), non ci sono le condizioni di contesto che consentono di fare veramente Scrum.

Non c’è niente di peggio di un Product Owner ridotto a fare il portavoce o il segretario. Non serve al team, non serve al cliente finale e – di fatto – neanche a se stesso.
Anche in questo caso è meglio portare alla luce con i propri interlocutori il tema della fiducia e della mancata delega per provare a capire quali azioni correttive possono essere messe in campo.

In sintesi…
E’ importante che il Product Owner abbia la libertà ed il diritto di dire dei no motivati al cliente finale, al cliente interno e al proprio management.
Senza questo potere non è posto nelle condizioni di fare al meglio il suo lavoro e di selezionare con cura ciò che è di maggior valore per gli utenti eliminando tutto ciò che è spreco.

10 criteri per suddividere le user stories

Quando singole user stories richiedono un effort di sviluppo che eccede la settimana o, più in generale, quando il team considera le storie troppo grandi per essere lavorate in un colpo solo è necessario riconsiderarle e suddividerle in parti più piccole.

E’ una condizione che capita di continuo ed il Product Owner deve essere allenato ad individuare ragionevoli alternative.
Ma è sempre possibile suddividere una funzionalità?
Sì, non solo è possibile, spesso è addirittura conveniente.
Storie più piccole hanno di solito stime più accurate, sono più gestibili, meno rischiose e offrono al Product Owner il vantaggio di una maggiore flessibilità nella gestione delle priorità.

Vediamo quali possono essere i criteri per dividere le user stories. Ve ne propongo dieci – quelli utilizzati più di frequente – ma è certamente possibile individuarne molti altri adatti alle esigenze di ciascuno (qui ne trovate una mappa mentale).
L’importante è evitare la trappola di suddividere le storie in base ai singoli task necessari per implementarle (i task non sono di alcun valore per l’utente finale!).

Dividere in base al tipo di dati

Questo criterio può risultare particolarmente utile quando si sta implementando una funzionalità di ricerca o nella gestione dei form.
Potremmo infatti individuare dei parametri base di ricerca ed una serie di criteri aggiuntivi o di filtri avanzati che possono essere rilasciati in un secondo momento.
Nella raccolta di dati mediante form possiamo decidere di gestire subito un primo set di informazioni (ad esempio quelle strettamente necessarie al nostro servizio) e abilitare dopo campi accessori e facoltativi. Questa soluzione ha anche il vantaggio di consentire una gestione incrementale delle condizioni di errore.

Dividere in base alle operazioni

In questo caso non ci concentriamo sui dati da gestire ma sul tipo di operazioni che è possibile effettuare sui dati.
L’esempio più classico è il “CRUD” (acronimo di create, read, update, delete), ovvero le operazioni di creazione, lettura, aggiornamento e cancellazione.
Il team di sviluppo può valutare che nel corso di una iterazione sarà in grado di realizzare solo parte del lavoro, ad esempio creare nuovi account per un servizio, associarli ad informazioni di dettaglio e consentirne la consultazione in lettura.
In un’iterazione successiva sarà possibile gestire operazioni di modifica ed eliminazione dei dati.

Dividere in base agli step di processo

Se gestite dei servizi avete inevitabilmente a che fare con processi e workflow.
Un criterio che può rivelarsi utile in questo scenario è segmentare i processi nei singoli step che li compongono.
Prendiamo ad esempio la registrazione di un account. Iniziate a sviluppare il form di raccolta dei dati, poi la visualizzazione in anteprima delle informazioni immesse e infine la pagina di conferma dell’avvenuta registrazione.
E’ ovvio che deciderete di rilasciare al pubblico quando la funzionalità di registrazione sarà del tutto completa, ma mediante un test interno potreste ad esempio scoprire eventuali problemi nella raccolta dei dati ed eliminare delle vulnerabilità prima del roll-out agli utenti finali.

Dividere in base ai flussi di processo

Sempre in tema di processi ed interazioni può tornare utile la decisione di separare “il migliore dei casi possibili” (l’happy path, la versione più semplice) da tutti i flussi in cui qualcosa va storto.
Gestiamo il caso ottimale e poi ci occupiamo di tutte le eccezioni.
Per tornare all’esempio della registrazione implementiamo il caso in cui l’utente non effettua alcun errore in tutto il processo e non ha necessità di modificare i dati inseriti. Creiamo poi ulteriori user stories per gestire i possibili errori e cambi di programma del nostro utente.

Dividere in base al tipo di utente

La stessa funzionalità potrebbe essere utilizzata da tipologie di utenti molto diverse tra loro (ad esempio utente basic, avanzato, utente interno, fornitore, operatore di call center, ecc.).
Ognuno dei nostri interlocutori è guidato da bisogni specifici. Concentriamoci in prima battuta sull’utilizzatore principale ed implementiamo la funzionalità in maniera ottimale per questo soggetto, dopo ci occuperemo degli attori secondari.
Se fate uso di personas vi torneranno molto utili per individuare i bisogni fondamentali che deve soddisfare la funzionalità in oggetto.

Dividere in base alla piattaforma

Nel mondo digitale è sempre più frequente che un servizio sia multi-channel.
Se la medesima funzionalità deve essere portata su tutti i canali si può pensare ad un rilascio incrementale sulla varie piattaforme (separare la parte web, dal sito mobile, da eventuali APP mobile).
E ancora, se abbiamo a che fare con e-commerce e affini, possiamo decidere di implementare diversi metodi di pagamento (carta di credito VISA, AMEX, Mastercard, Pay Pal, ecc.) in più step.
La prima storia sarà la più onerosa in termini di effort, le successive saranno più semplici in quanto variazioni  sul tema.

Dividere in base al tipo di requisiti (funzionali e non)

Se l’ambito in cui lavoriamo prevede un’interazione con gli utenti (e quale servizio non prevede oggi un front-end?) dobbiamo per forza curare i requisiti non funzionali.
Ricadono tra questi gli aspetti di performance, scalabilità, usabilità, layout, ecc.
Di solito in questi casi si decide di lavorare prima l’essenza di una funzionalità (il suo aspetto core) e, solo in un secondo momento, i requisiti non funzionali.
Il motto è “make it work, then make it faster”. Prima mettiamo in piedi il motore e verifichiamo che sia effettivamente funzionante, poi lo ottimizziamo con un approccio incrementale e lo vestiamo.

Dividere in base alle priorità

La medesima funzionalità può rispondere ad esigenze di natura diversa (e diversa priorità).
In questo caso tentiamo di suddividere questa funzionalità in user stories più piccole individuando cosa è un must per il rilascio e cosa è un attributo secondario.
Vi ricordate l’approccio 80/20? E’ una tecnica applicabile non solo al backlog ma, il più delle volte, anche a singole user stories.
In generale se vediamo che la medesima storia soddisfa più bisogni di priorità diversa è una buona idea frammentarla ulteriormente.

Dividere in base ai criteri di accettazione

Quando una storia è associata ad un numero consistente di criteri di accettazione è molto probabile che la sua dimensione in termini di effort sia elevata… fosse solo per i test che devono verificarne l’effettivo funzionamento.
In questi casi di solito sollevo la questione con il team: siamo in grado di rispettare tutti i criteri in una volta sola (un unico sprint)? O è più ragionevole pensare di soddisfarne una parte e demandare il resto ad iterazioni successive?

Dividere in base al rischio

Può capitare che il team debba lavorare su ambiti poco conosciuti, con tecnologie nuove o integrando pezzi di terze parti.
In questi casi anche la stima dell’effort può risultare ardua.
Quando non si hanno le idee chiare torna utile suddividere la storia in una prima parte di analisi ed una successiva fase di implementazione. In questo modo prima si acquisiscono le conoscenze necessarie per definire meglio il contesto e le possibili soluzioni con una spike e solo poi si parte a scrivere codice.

E voi? Quali criteri utilizzate più di frequente?
Quali preferite?
Quali altri avete sperimentato?