Ottobre 1, 2022 - di Giuseppe Costanza
ICE Score: assegnare le priorità nello sviluppo del prodotto
Grazie a questo articolo, imparerai a utilizzare l’ICE Score, una metodologia che permette di semplificare la definizione delle priorità, durante il processo di sviluppo di un prodotto digitale.
Per rendere tutto più chiaro, partirò spiegandoti cos’è il Backlog, nonché il punto di riferimento per tutto il product team, per poi introdurti come definire le specifiche per lo sviluppo di un prodotto.
Infine, cercherò di dare risposta alla domanda alla quale tutte le persone coinvolte nello sviluppo di un prodotto digitale si sono imbattute:
“Come posso stabilire le priorità di sviluppo per il mio prodotto?“
Eccoti una panoramica di ciò che leggerai:
Cos’è il Product Backlog?
Come precedentemente accennato, il Backlog è un elenco ordinato di funzionalità che si intende sviluppare.
È, anche, uno strumento di comunicazione e condivisione utilizzato dai team, per questo deve essere comprensibile da tutti i suoi membri.
Riprendendo una metafora già usata in passato su Product Heroes, il primo errore da evitare è l’approccio “lista della spesa”.
Io preferisco immaginare il Backlog come una “lista dei desideri”.
Mi spiego meglio:
-La lista della spesa è una lista chiusa, dove non ci sono priorità, tutto è importante e deve essere fatto;
-La lista dei desideri, al contrario, è una lista aperta, racconta le nostre aspirazioni e desideri, è flessibile ed aperta al cambiamento.
A mio avviso, come i desideri, il Backlog può essere mutevole e in continua evoluzione; quindi, cerco di avere sempre ben chiara la differenza tra i desideri a breve e a lungo termine.
Cosa c’è dentro il Product Backlog?
All’interno di un Backlog possiamo trovare:
- Temi: ampie aree funzionali all’interno del tuo prodotto.
(p. es: “dashboard delle vendite” o “pagina di ricerca dei prodotti” in un e-commerce); - Storie Epiche: funzionalità molto ampie all’interno di un tema.
(p. es: la funzionalità “carrello” in un e-commerce o la sezione “profilo utente”); - User Story: sono dei piccoli task chiari e ben definiti, pronti per essere sviluppati (solitamente realizzabili in pochi giorni di lavoro, indipendenti da altri ancora in lavorazione);
- Bug: questo non ci sarebbe bisogno di spiegarlo.. il bug è un errore nel software che deve essere corretto.
- Migliorie tecniche: tutte le attività di manutenzione del software (p. es: il refactoring, la diminuzione del debito tecnico).
Se non hai idea di cosa stiamo parlando chiedi ad un amico sviluppatore 🙂
Solitamente queste attività vengono viste come perdite di tempo da chi non è un tecnico; quindi, la bravura del Product Manager sta nel capire quali migliorie tecniche sono superflue e quali, invece, portano un beneficio al business.
Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 70 pagine su Team Cross-funzionale, Agile, Scrum vs Kanban, User Story, etc. ti presentiamo Agile Starter Kit, una cartella condivisa su Google Drive pensata per gli eroi come te che stanno iniziando il proprio viaggio nel Digital Product Management.
Come scrivere le User Story?
Quando ci si approccia alla metodologia Agile e all’uso del Backlog, la parte più difficile è riuscire a scrivere delle User Story efficaci.
Sarebbe necessario un approfondimento specifico, ma qui mi limito a elencare le caratteristiche base secondo la dottrina Agile:
- Indipendente dalle altre storie;
- Negoziabile – può essere sviluppata in modi differenti.
- Valuable – porta valore al nostro prodotto, o meglio ai nostri utenti.
- Estimable – è possibile valutare il tempo necessario per svilupparla.
- Small – deve essere sviluppabile in pochi giorni.
- Testabile – quando la User Story è completa deve essere possibile valutare se l’obiettivo è stato raggiunto.
Forse avrai notato che le iniziali, delle caratteristiche in elenco, formano l’acronimo “INVEST”.
Ora conosci un trick da vero Agilista! 🙂
Una buona User Story deve essere chiara!
Chiunque nel team, a prescindere dal ruolo, deve avere chiaro qual è il risultato atteso e il valore che la funzionalità porterà al prodotto.
Chi scrive le User Story?
Le User Story vengono solitamente definite dal Product Manager, partendo da una chiara visione del valore per il business, ma possono essere suggerite da qualsiasi stakeholder.
Nel Backlog è anche possibile avere storie incomplete e non ben definite; quindi, il Product Manager deve accertarsi che le User Story, con maggior priorità, siano scritte in modo chiaro e abbiano tutti i dettagli per poter essere prese in carico dal team di sviluppo.
Così, passiamo ora al tema centrale di questo articolo, Ovvero: come stabilire le priorità nello sviluppo del tuo prodotto?
ICE Score
Prima di parlarti dell’Ice Score e della sua metodologia, bisogna chiarire un concetto fondamentale: le risorse, che si hanno a disposizione, sono limitate e sempre lo saranno.
Non è possibile avere tutto e subito e, nel tuo ruolo di Product Manager, troverai sempre qualcuno che metterà in discussione le priorità che hai definito.
Per questo è importante avere un metodo razionale e strutturato per decidere le priorità.
L’ICE Score è un metodo per assegnare le priorità a:
- epiche (il livello più alto di espressione del bisogno di un utente);
- user stories (strumento che consente di descrivere le funzionalità di un dato sistema dal punto di vista dell’esperienza dell’utente).
Abbiamo visto che nel Product Management è utile per riordinare il Product Backlog.
Spesso viene preferito ad altri metodi per la sua chiarezza e per la facilità di condivisione con tutto il team.
ICE Score: cos’è
Come già accennato, l’ICE Score è un framework semplice e immediato, utile per strutturare le proprie analisi.
Il suo punteggio si ottiene dalla moltiplicazione dei 3 valori da cui prende il nome:
- Impact: quale impatto porta la User Story sulle metriche che stai cercando di migliorare (per es. sul conversion rate);
- Confidence: quanto è fiducioso il team sull’impatto che avrà la User Story avrà e quanto è sicuro di essere in grado di svilupparla;
Ease: è la stima del tempo e il numero di risorse richieste per mandare in produzione la User Story (rappresenta anche la facilità/velocità nel rilasciare).
ICE Score vs RICE
Chiaramente, nel mondo del Product Management, esistono moltissimi metodi che aiutano le figure del settore a definire le priorità.
Oltre all’ICE Score, molti Product Manager, fanno utilizzo della variante RICE.
Il metodo RICE è un framework che permette di definire i prodotti, le funzionalità e le iniziative da inserire all’interno della roadmap assegnando loro un punteggio, sulla base di quattro fattori:
- Reach: una stime delle persone che credi di poter raggiungere, attraverso la tua iniziativa, in un determinato periodo di tempo.
- Impact: può rappresentare un obiettivo quantitativo (p.es: nuove conversioni) o qualitativo (p.es: aumentare la soddisfazione dei clienti)
- Confidence: come per l’ICE Score, è la componente di fiducia che si ha circa la corretta realizzazione del progetto.
- Effort: lo sforzo che deve essere impiegato.
Ma perché molti Product Manager preferiscono utilizzare l’ICE Score?
ICE Score: quando è preferibile usarlo e perché
L’ICE Score viene scelto per la sua chiarezza, semplicità d’utilizzo e condivisione.
Vediamo come impiegarlo: facciamo finta che tu sia il Product Manager per un Social Network e il tuo obiettivo sia quello di aumentare il numero di visite alla pagina profilo degli utenti.
Come metrica di successo consideriamo l’incremento del numero di visualizzazioni alla pagina profilo.
Le User Story che vuoi sviluppare sono le seguenti:
- Ottimizzazione SEO
la pagina profilo non è ottimizzata per la visibilità su Google.
Da una comparazione fatta con altre aree del sito sappiamo che ottimizzando possiamo incrementare del 30% il numero di utenti che da Google Search atterrano alla pagina profilo. - Funzione Condividi via mail
Questa User Story è abbastanza semplice: si tratta di aggiungere un bottone che consenta di inviare un link via mail ad una pagina profilo. Non abbiamo dati precisi a riguardo ma possiamo immaginare che mettendo il bottone in bella vista, molti utenti vorranno inviare un link alla pagina ai propri amici, aumentando così il numero di visite in ingresso. - Galleria di immagini nella pagina profilo
Sappiamo che sul nostro Social Network le immagini sono i contenuti che ricevono più interazioni; possiamo immaginare che se aggiungiamo una galleria di immagini nei profili degli utenti più persone saranno interessate a visitarla.
Non abbiamo stime precise, ma guardando i dati delle altre sezioni del sito sappiamo che le gallerie di immagini attirano in media il 10% in più di utenti.
Bottoni Social Sharing
Simile alla funzione “Condividi via mail”, ma in questo caso l’idea è di aggiungere dei bottoni per condividere la pagina sui principali Social Network (Facebook, Twitter).
Anche qui, non abbiamo dati per stimare l’impatto ma immaginiamo che gli utenti saranno più stimolati a condividere la pagina avendo dei bottoni dedicati.
ICE Score: come si calcola
Partiamo attribuendo un punteggio a ciascuna delle 3 variabili dell’ICE Score per ogni User Story:
- Ottimizzazione SEO pagina profilo:
-Con i dati visti sopra (+30% utenti che arrivano da Google Search) sappiamo che l’impatto può essere importante; quindi, attribuiamo un valore di impatto alto (7).
-Inoltre, l’ottimizzazione SEO è un’attività che abbiamo già fatto in passato, perciò il team sa cosa deve fare e non ci dovrebbero essere particolari intoppi: inseriamo un 7 per la Confidence.
-Per quanto riguarda la facilità/velocità sappiamo che il lavoro ha una difficoltà media, richiedendo tante sotto-attività -ma tutte con poca complessità-, inseriamo un 5 per la variabile Ease.
- Funzione “Condividi via mail”:
-Non possiamo aspettarci crescite esponenziali in quanto l’aumento di visualizzazioni (la nostra metrica di partenza) dipende da due azioni (l’invio della mail da parte di un utente e il click sul link nella mail da parte del ricevente). È meglio avere la consapevolezza di poter esercitare un impatto basso (2).
-Anche la Confidence è bassa in quanto non abbiamo nessun dato o riferimento che possiamo usare (2).
-Il team di sviluppo ha stimato la facilità di realizzazione come molto alta, inseriamo un 8 per il parametro Ease. - Galleria di immagini nella pagina profilo:
-Per questa User Story abbiamo dei dati di riferimento su cui basarci e le aspettative sono molto alte, settiamo quindi l’Impact a 8.
-La Confidence la teniamo su 5 in quanto non siamo molto sicuri dei tempi di sviluppo e del successo che riscontrerà.
-Dal confronto con il team possiamo stimare che lo sviluppo richieda più tempo rispetto alle altre User Story analizzate, inseriamo quindi 2 per Ease.
Bottoni Social Sharing:
–Ogni condivisione social è visibile da più persone, inseriamo quindi un impatto doppio (4).
-Da un punto di vista tecnico sappiamo essere la funzione più semplice da implementare tra quelle in esame, attribuiamo quindi 7 alla Confidence e 10 alla Ease.
Un’occhiata ai risultati
Come puoi vedere i calcoli sono molto semplici e possono essere fatti anche a mente.
Per i meno esperti in matematica, riporto la tabella su Google Sheet con i calcoli (puoi semplicemente duplicare il documento, inserire le tue User Story e stabilire le tue priorità di prodotto).
Quando usi l’ICE Score ricorda sempre che non è un metodo scientifico, i valori inseriti sono soggettivi e relativi al contesto (es. un task potrebbe apparire al team difficilissimo oggi e molto facile fra 2 mesi).
l’ICE Score è anche uno strumento di comunicazione e condivisione, quando ti confronti con il team o altri stakeholder mantieni visibili le 3 variabili che determinano il punteggio finale in modo da garantire trasparenza.
I numeri rappresentano delle stime, tieni sempre nota di come sei arrivato a definire i punteggi e sii aperto a rimetterli in discussione.
Conclusione
Nei paragrafi precedenti ho raccontato alcuni dei principali strumenti a disposizione del Product Manager per pianificare il lavoro del proprio team e stabilire le priorità nello sviluppo di prodotto.
A prescindere se userai il Backlog, le User Story e la prioritizzazione tramite ICE Score, tieni sempre a mente che nello sviluppo di prodotto sono fondamentali la comunicazione, la condivisione e la trasparenza con il team e con tutte le persone in azienda coinvolte nello sviluppo di prodotto.
Non mi resta che augurarti buona prioritizzazione!
