2. www.5dvision.com 2
Work agreement
Oggi impariamo:
• Come minimizzare un MVP
• Tecniche di prioritizzazione
• Come creare Product Journey
Maps
• MVP e MDP
• Roadmapping e release planning
Siamo d’accordo a:
• Partecipare attivamente
• Lavorare in team
• Non usare il cellulare o PC
• Una conversazione alla volta
3. www.5dvision.com 3
Il tuo MVP mattutino
Da quando suona la sveglia la
mattina….
Scrivi l’elenco delle cose che fai per
prepararti per uscire di casa, e il
tempo che serve per farle
Per esempio:
1) Spengo la sveglia
2) Mi stiro nel letto
3) Mi alzo e vado in bagno
4) Faccio la barba
5) Ecc….
5 min
6. www.5dvision.com 6
MVP
Un Minimum Viable Product (MVP) e’:
“la versione di un nuovo prodotto che
consente al team di raccogliere
la massima quantità di apprendimento
convalidato sui propri clienti
con il minimo sforzo”
- Eric Ries
1
2
3
8. www.5dvision.com 8
Una vista più completa dell’MVP
Features e funzionalità
Metriche e feedback
Customer experience
9. www.5dvision.com 9
Your next adventure awaits in space
La nostra nuova
startup
Prenota a compra biglietti per viaggi
sulla Luna
Prenota biglietto, viaggia, e condividi la
tua esperienza con altri
Vettori forniti da SpaceX, Boeing, Orbital
APK, Blue Origin, Virgin Galactic
Pensa a Expedia per viaggi sulla Luna
Moon go.
10. www.5dvision.com 10
Viaggia e
esplora
Cerca e
compra
Torna e
condividi
• Preparati a partire
• Sali a bordo
• Lancio e volo
• Atterraggio
• Esplora Luna
• Lancio di rientro
• Scopri servizio
• Decidi di partire
• Cerca biglietto
• Seleziona vettore
• Prenota viaggio
• Torna sulla Terra
• Condividi
immagini e video
• Invita amici
• Cerca prossimo
viaggio
Moon go.
13. www.5dvision.com 13
Scegli un possibile segmento di
clientela
Sviluppa una “User Persona”
Una Persona per team
Persona: Chi è il tuo cliente ideale?
7 min
14. www.5dvision.com 14
Moon go.
PRE DURING POST
Viaggia e
esplora
Cerca e
compra
Torna e
condividi
• Preparati a partire
• Sali a bordo
• Lancio e volo
• Atterraggio
• Esplora Luna
• Lancio di rientro
• Scopri servizio
• Decidi di partire
• Cerca biglietto
• Seleziona vettore
• Prenota viaggio
• Torna sulla Terra
• Condividi immagini e
video
• Invita amici
• Cerca prossimo viaggio
15. www.5dvision.com 15
3 fasi nel Customer Journey
PRE: Prima della “core experience”
DURING: l’essenza della user
experience
POST: Dopo la “core experience”
7 min
18. www.5dvision.com 18
MoSCoW
• Must - Necessario per core experience
• Should - Importante ma non necessario
• Could - Utile, se avanza tempo
• Won’t - Non ora, magari in futuro
WSJF
• Weighted Shortest Job First
Buy-A-Feature
• Metodo interattivo con I tuoi clienti
Tecniche di prioritizzazione
22. www.5dvision.com 22
Thank you
Valerio Zanini
vzanini@5dvision.com
www.5dvision.com
5dvisionllc
User Story Mapping:
Discover the Whole
Story, Build the Right
Product
- Jeff Patton
Deliver great products
that customers love
- Valerio Zanini
Notas del editor
5 min first round
2 min second round
2 min third round
Discussion
A couple of comments:
1 – with less time, do not reduce quality. Only work on scope, not quality
2 – some activities may be too big work at splitting them into smaller User Stories
Explain the background of the project to provide context
Retail Bank project
Salesforce app
18 stages, from when customer enters the branch, to when they leave + follow up
How does it tie to the PRE and POST customer journey map discussion? Go beyond the CORE experience
Explain «Learning» as the main purpose of the MVP.
Validated learning with customers: validation is about the hypotheses that are at the core of the MVP. Customers are those we should validate with
With minimum effort: something that’s quick and allows us to validate ASAP
MVP is not a minimum set of features. It’s not a Beta release.
It should include the full customer experience elements to validate the business hypotheses.
Need a good example!
This slide works!
The MVP should not be a Beta release – i.e. not stop at the Technology dimenion, but rather expand and cover the Business and Human dimensions too
Show an image of a finished mind map. Give an idea on where this should go
Share other uses for a mind map. For example, I use it to jot down ideas on how to write a chapter of my book. Deb uses it to plan a legal document.
Explain the steps so that people understand the mechanics of the exercise.
5 min (maybe more)
Make sure people refer to a specific user, real or fictittous.
Give it a name
5 min – 7 min
Explain the meaning of the During phase, and then the purpose of the PRE and POST.
Give example – i.e. C1: a banker who is stressed because his account has been overdrafted. He decides he needs to talk to a banker, and searches the nearest branch. (PRE)
POST could be the same customer logging in on online banking to confirm his account is OK.
Talk about the emotional journey of the customer throughout these experiences.
AT THIS POINT IT SHOULD BE 1 HOUR MARK IN THE WORKSHOP
7 min (maybe more)
Use a customer’s point of view, not the business’s
5 min
Sorting the cards on the table to make the line for the journey
AT THE END OF THIS, SHOULD MARK 1.5 HOURS IN THE WORKSHOP
15 mins
Make sure they think about:
These are features, i.e. activities the customer does. So, no general benefits like «easy and understable» but activities like «login» «search for flights» etc.
They should be expressed from a customer’s point of view.
Talk briefly about Buy-A-Feature
Talk briefly about WSJF
Explain MoSCoW
Must have
Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from Must have, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered an acronym for the Minimum Usable SubseT.
Should
Requirements labeled as Should are important but not necessary for delivery in the current delivery timebox. While 'Should have' requirements can be as important as 'Must have', they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.
Could
Requirements labeled as Could are desirable but not necessary, and could improve the user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.
Won't
Requirements labeled as Won't have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, 'Won't have' requirements are not planned into the schedule for the delivery timebox. 'Won't have' requirements are either dropped or reconsidered for inclusion in later timeboxes.
Wikipedia