Minimum Viable Product o del valore in una fetta di torta

MVP e Release di prodotto

Nella pianificazione di una release ci si trova spesso a valutare a che punto sarà disponibile il prodotto per l’utente finale. Ma se adottate l’idea del Minimum Viable Product potreste decidere di rilasciare una “early beta” del prodotto per testare le vostre assunzioni in termini di ipotesi di valore e ricevere feedback dagli utenti quando lo sviluppo è ancora in corso.

La strategia dell’MVP presenta indubbiamente molti vantaggi: rilasciamo un prodotto (o una funzionalità) ad uno stato essenziale, totalmente “no frills”, perché desideriamo capire ciò che i clienti vogliono veramente, non ciò che dicono di volere o ciò che pensiamo vorrebbero.

Per anticipare il più possibile questo tipo di apprendimento potreste decidere di dare in mano ad una cerchia ristretta di utenti poco più che una presentazione o un wireframe.
Se non è questo il vostro caso, come spesso non lo è per me, rilascerete software funzionante ma dovrete identificare il set minimo di funzionalità in grado di comunicare il valore del vostro prodotto.

Cosa inserire in un MVP

Non è un’operazione così banale come può sembrare a prima vista…
Dovrete far comprendere a chi sviluppa qual è il valore del prodotto dal punto di vista dell’utente finale, un valore che sta nella soluzione di un problema, nella “slice” – la più piccola fetta compiuta – e non in un layer.

Questo approccio dal punto di vista di chi sviluppa è solitamente molto più oneroso perché significa aggredire più sistemi contemporaneamente invece che lavorare “a strati”.
Comporta molto più effort ma, allo stesso tempo, abbatte decisamente il rischio. Insomma, avrete la vostra bella negoziazione da fare con il tech team ma ne vale la pena.

Per rilasciare un MVP dovete concentrarvi sul COSA, su un piccolo pezzo, una singola funzionalità purché finita e funzionante. Fatela funzionare, fatela testare sul campo anche solo da un’unica tipologia dei vostri utenti e – intanto che analizzate i primi feedback – valuterete quali parti mancanti vale la pena di integrare e come.

Cos’è valore per il cliente?

Tenete presente che ciò che interessa all’utente è il servizio nel suo complesso, ma dovendo “fare a fette un elefante” nella mia esperienza ho trovato più utile un approccio verticale piuttosto che orizzontale.
In un servizio e-commerce, ad esempio, l’utente valuterà le diverse funzionalità: la navigazione nel catalogo dei prodotti, la ricerca, il carrello per l’acquisto, l’archivio degli ordini. Quale beneficio trarrebbe se il layer dei dati e quello applicativo fossero perfettamente compiuti ma non fosse possibile neanche consultare il catalogo dei prodotti?

E’ esattamente la differenza che passa tra una fetta di Sacher – per quanto piccola – ed uno strato di torta al cioccolato. Qual è più appetitosa in un uggioso pomeriggio di pioggia invernale? Cosa preferireste mangiare per merenda?
Io non ho dubbi!

P.S.: e non ditemi che non avete mai assaggiato la Sacher Torte perché se no avete ben altri problemi che individuare il vostro Minimum Viable Product …

Continuiamo così, facciamoci del male!  (… grazie Moretti!)

Mappa mentale per suddividere le user stories

Story-Splitting-Flowchart-Thumbnail

Come orientarsi tra i tanti criteri per dividere user stories di grandi dimensioni?
Mi riprometto di scrivere un post più approfondito su questo tema, ma nel frattempo ho scovato in rete questa mappa visuale che sintetizza a colpo d’occhio le alternative più comuni.
Per chi, come me, ama schematizzare informazioni e processi è un piccolo capolavoro da condividere.

Fonte: Agile For All – “New story splitting resource”

Le buone user stories sono INVEST

L’acronimo INVEST creato da Bill Wake nel 2003 è un trucco che i Product Owner possono utilizzare per ricordare le qualità di una buona user story.
Cosa significano le iniziali? Semplicissimo!

IndipendentIndipendenti

Quando le user stories non sono indipendenti tra loro possono produrre stime non corrette, vincoli di implementazione e potenziali rigidità nella pianificazione dei rilasci.
L’ideale è segmentare le storie in modo tale che possano essere implementate secondo qualsiasi ordine (qui ho parlato dei criteri di suddivisione).

Quando ci troviamo di fronte a delle dipendenze possiamo provare alcune soluzioni alternative:

  • combinare insieme le storie interessate (purché si possano concludere in uno sprint)
  • suddividerle in una maniera differente
  • segmentarle in storie più piccole.

Quando proprio non è possibile scrivere user stories indipendenti è meglio definire un ordine di implementazione e fornire stime differenti per la prima storia e le successive (ad esempio 3 punti per la prima e 1 per le successive).

NegotiableNegoziabili

Una delle qualità più apprezzabili delle user stories – dal mio punto di vista – sta nel fatto di non essere contratti scritti nella pietra una volta per sempre.
Le storie sono brevi descrizioni delle funzionalità desiderate. Catturano l’essenza di una richiesta, non le specifiche di dettaglio.

In Scrum la definizione dell’ambito di una storia (il cosidetto “scope”) non è come nel processo waterfall appannaggio esclusivo del project manager; i dettagli sono negoziabili e vengono negoziati perché emergono dai dialoghi tra il cliente, il product owner e il team.

La user story è un invito a conversazioni future.

ValuableDi valore

In un mondo ideale tutte le storie sono di valore per l’utente finale; nella realtà non è sempre così, ma è utile tenere a mente questa aspirazione e interrogarsi sul vero beneficiario della user story (a volte può essere il cliente che paga lo sviluppo software, il committente interno, lo sponsor, il reparto vendite o altri tipi di stakeholder).

L’importante è evitare di perdere tempo (e soldi) in storie che non solo di valore per nessuno e provare a ricercare benefici “spendibili” anche nelle storie tecniche.

EstimableStimabili

Dal momento che Scrum prevede iterazioni time-boxed che siano autoconclusive, la stima di una storia e del tempo necessario per produrla è un’attività fondamentale nel team.
Quando la valutazione risulta difficile siamo solitamente di fronte ad uno di questi problemi:

  1. gli sviluppatori non conoscono perfettamente il dominio e non si sentono confidenti nel dare una stima iniziale
  2. hanno una conoscenza parziale della tecnologia da utilizzare
  3. oppure le storie risultano troppo grandi o poco chiare.

Nei primi due casi si può cominciare a programmare un’attività di analisi da parte del team (una spike) per arrivare a una stima sufficiente dell’ordine di grandezza delle attività; negli altri è il Product Owner che deve farsi carico di segmentare di più le storie e dettagliare maggiormente i criteri di accettazione.

Size appropriately or SmallDella giusta dimensione

La dimensione giusta è “quanto basta”… e come nelle ricette di cucina si migliora con la pratica, perché non è sempre evidente a cosa corrisponda il fatidico q.b.
Una cosa è certa: se le storie sono troppo piccole o troppo grandi ve ne accorgerete!
Il team non mancherà di farvelo notare già in fase di refinement, quando potrebbero sorgere problemi nella stima.
Anche in questo caso bisognerà dividere le storie tanto grosse da non poter entrare in uno sprint (di solito sono epiche nascoste!) o combinare più user stories affinchè l’effort complessivo comporti almeno una mezza giornata di lavoro.

TestableTestabili

Al termine di ogni sprint vengono rilasciate delle funzionalità che sono “done” e dev’essere possibile dimostrare al cliente finale questo stato “finito”.
Ecco perché nella user stories non possono mancare criteri di accettazione effettivamente misurabili, ognuno dei quali possa poi essere misurato attraverso i test.
Quando i test passano (proviamo ad automatizzarne il più possibile) dimostriamo che le storie sono complete.

INVEST!

Ovvero user stories indipendenti, negoziabili, di valore, stimabili, della giusta dimensione (né troppo piccole né troppo grandi) e testabili.

L’articolo originale di Wax si intitola INVEST in Good Stories and SMART Tasks.