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”

L’80/20 applicato al Backlog

Cosa succederebbe se provassimo ad applicare il principio di Pareto (la famosa regola dell’80/20) al nostro backlog? E’ questa la riflessione a cui ci invita Stefan Haas – Agile coach con molti anni di esperienza sul campo – in uno degli ultimi articoli del suo blog.

Siamo in grado di individuare quel 20% di funzionalità che producono l’80% della soddisfazione dei nostri utenti finali? Abbiamo idea di quali siano l’80% dei requisiti che producono scarso o nullo valore per i nostri clienti?
Al di là della provocazione, sappiamo per esperienza che non tutto ciò che è contenuto nel backlog è realmente di valore per l’utente e – nonostante ciò – è nostro compito trovare spazio anche per diversi tipi di attività – ad esempio – di aggiornamento dei sistemi, business intelligence o per adeguamenti di legge.

E’ in ogni caso interessante fermarsi a riflettere sull’opportunità di individuare ed avere sempre ben presente quel 20% di funzionalità che rappresentano il cuore dei nostri prodotti, quel 20% di un’epica (poi suddivisa in user stories) che ne rappresenta l’essenza, quel 20% di attività quotidiane del team che produrrà il maggior valore nel corso dell’iterazione.

Il principio può essere infatti applicato a tutti i livelli: al prodotto nel suo insieme, alle epiche, alle singole user stories o – segmentando ancora di più – ai task.
La sfida è individuare quel 20% critico del backlog in grado di produrre l’80% del valore finale e  mettere in priorità queste attività focalizzando l’impegno del team soprattutto su di esse.