È possibile rilasciare fin da subito un software funzionante che l’utente finale possa utilizzare?
Noi dell’ACT abbiamo fatto un esperimento simulando uno Scrum Sprint Planning.
Ci siamo inventati un’esigenza che in questo momento storico può essere reale: la creazione di una piattaforma di prenotazione on-line dei prodotti da asporto su un sito già esistente di un ristorante per dare la possibilità all’utente finale di prenotare il pranzo o la cena.
L’idea iniziale è stata quella di:
- poter caricare sul sito in maniera dinamica tutte le pietanze con relativi ingredienti, possibili allergeni, costi e quantità disponibili
- selezionare dal menu piatti e quantità
- selezionare l’orario del delivery
- selezionare la modalità di delivery (da ritirare in loco o consegna a domicilio)
- selezionare il tipo di pagamento (contanti, bancomat, ecc..)
- dare conferma dell’avvenuta prenotazione
- dare la possibilità di modificare l’ordine fino a qualche ora prima del delivery
Insomma una serie di possibilità utili al consumatore.
Ovviamente non è possibile avere tutto subito, immediatamente, e avere anche la pretesa di aver implementato tutte le funzionalità che sicuramente saranno ritenute utili.
Quindi? Come fare? Come procedere?
Siamo partiti dall’inizio, dalla vision del servizio e ci siamo chiesti quali potevano essere le User Story necessarie alla sua realizzazione; così su una board Miro abbiamo creato uno Story Mapping e tutte le storie con relative personas e flusso di lavoro.
Ci siamo chiesti, poi, se il progetto poteva avere senso e come poter validare le nostre ipotesi con il minimo sforzo; così ci siamo dati come obiettivo del primo Sprint quello di fornire le funzionalità necessarie per vedere se il prodotto poteva funzionare.
Ottimo inizio: avevamo creato un primo Product Backlog e lo Sprint Goal del primo Sprint.
Quindi, escludendo il superfluo, rimanevano solo le funzionalità per il MVP.
Ma cos’è l’MVP? Ovvero cos’è Il Minimum Viable Product? Minimo prodotto vitale, sostenibile, necessario, ma per chi? Ma per le personas individuate precedentemente.
Ecco, allora, che poteva avere inizio la scrematura.
Sono state selezionate le storie che nella visione del Product Owner potevano dare valore sin dal primo Sprint e grazie alle quali si poteva raggiungere il Goal:
Su queste storie si è aperto il nostro meetup che ha visto protagonisti il PO, lo Scrum Master e cinque Sviluppatori, tutti selezionati volontariamente tra i partecipanti.
La discussione sul significato delle User Story, sulla loro fattibilità nell’arco di uno Sprint e sul raggiungimento dello Sprint Goal hanno animato la serata.
I sette volontari sono stati bravissimi e hanno simulato alla perfezione lo Sprint Planning.
Qui di seguito lo Sprint Backlog.
Supponendo che il team riesca a completare tutti i task selezionati, con questo “minimo set di User Story” potevamo essere in grado di fornire al cliente una prima versione funzionante del prodotto, certo con diverse limitazioni, ma pur sempre funzionante.
In questo modo abbiamo 2 vantaggi:
- avere un feedback dal cliente a breve giro
- testare direttamente sul campo se il prodotto può incontrare il favore del pubblico
I feedback ricevuti indicherebbero che l’obiettivo del Meetup sia stato raggiunto.
Un particolare grazie va a tutti coloro che hanno contribuito attivamente alla realizzazione dell’evento:
- Alma Maria Del Campo Vara che ha creato lo User Story Map
- Daniel Palmisano che ha contribuito alla selezione delle User Story per il primo Sprint
- Alessandro Dellafiore che ha moderato il meetup
- Giancarlo Degani nel ruolo di Product Owner
- Paolo Pustorino nel ruolo di Scrum Master
- Antinea, Rossana, Annalisa, Annita e Giacomo nel ruolo di Sviluppatore
