Come stabilire le priorità nello sviluppo di prodotto.

In questo articolo ti spiego come definire le priorità nel processo di sviluppo di un prodotto digitale utilizzando alcuni strumenti della metodologia Agile.

Partendo dal Backlog, ovvero il punto di riferimento per tutto il team di prodotto, ti spiegherò come definire le specifiche per lo sviluppo del tuo prodotto. Infine cercherò di dare risposta alla domanda in cui tutte le persone coinvolte nello sviluppo di un prodotto digitale si sono imbattute:

“come posso stabilire le priorità di sviluppo per il mio prodotto?“

Cos’è il Product Backlog?

Partiamo subito dal primo passo: Il Product Backlog. Il Backlog è un elenco ordinato di funzionalità che si intende sviluppare.

Screenshot di Jira, uno dei software più usati per organizzare il Product Backlog e mettere in priorità i task.
Jira è uno dei software più usati per gestire il Product Backlog

Riprendendo una metafora già usata in passato su Product Heroes, il primo errore da evitare è l’approccio “lista della spesa”, 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. 

Come i desideri, il Backlog può essere mutevole e in continua evoluzione. Personalmente cerco di avere sempre chiaro quali sono i miei desideri di breve termine, mentre i desideri a lungo termine sono vaghi ed evolvono nel tempo.

Il backlog come lista dei desideri
Come i desideri, il Backlog può essere mutevole e in continua evoluzione.

Devi sapere però che il Product Backlog è anche uno strumento di comunicazione e condivisione, appartiene al team e deve essere comprensibile da tutti i suoi membri.

Cosa c’è dentro il Product Backlog?

All’interno del Backlog trovano spazio Temi, Storie Epiche, Storie pronte per essere sviluppate, Bug e Migliorie Tecniche. Proviamo a dare un senso ad ognuna di queste:

  • Temi: ampie aree funzionali all’interno del tuo prodotto. Per es. “Dashboard delle vendite” o “Pagina di ricerca dei prodotti” in un e-commerce.
  • Storie Epiche: funzionalità molto ampie all’interno di un tema, per es. la funzionalità Carrello in un e-commerce o la sezione Profilo Utente.
  • User Story: sono dei piccoli task (solitamente realizzabili in pochi giorni di lavoro), indipendenti da altri task in lavorazione, chiari e ben definiti, pronti per essere sviluppati.
  • Bug: questo non ci sarebbe bisogno di spiegarlo.. il bug è un errore nel software che deve essere corretto.
  • Migliorie tecniche: rientrano qui tutte le attività di manutenzione del software come ad esempio 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 è tecnico. Il Product Manager deve capire quali migliori tecniche sono superflue e quali portano un beneficio al business.

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. Sarà necessario un approfondimento dedicato, al momento mi limito qui 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!

le caratteristiche di una buona user story: INVEST
L’acronimo INVEST descrive le caratteristiche base delle User Story

Tratteremo la scrittura delle User Story in un articolo dedicato, per il momento aggiungo solo l’aspetto per me fondamentale di una buona User Story: deve essere chiara! Chiunque nel team, a prescindere dal ruolo, deve avere chiaro quale sia 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. Ovvero membri del team, colleghi di altri dipartimenti (marketing, customer service) o persino dagli utenti. Nel Backlog è possibile avere anche storie incomplete e non ben definite. Il Product Manager deve accertarsi che le User Story con maggior priorità siano scritte in modo chiaro e che abbiano tutti i dettagli per poter essere prese in carico dal team di sviluppo.
Va benissimo avere desideri vaghi per il futuro, ma devi avere assoluta chiarezza su ciò che deve succedere nelle prossime settimane.

Passiamo ora al tema centrale di questo articolo.

Come stabilire le priorità nello sviluppo del tuo prodotto? Prova l’ICE Score!

Partiamo dalla dura consapevolezza che le risorse 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. È pertanto fondamentale avere un metodo razionale, strutturato e chiaro per decidere le priorità. Il mio consiglio è di partire da un’analisi di impatto/valore e difficoltà/rischio.

Impact Confidence Ease = ICE Score
ICE Score è un framework semplice, immediato.

L’ICE score è un framework che puoi usare per strutturare la tua analisi. Quello che mi piace di questo metodo sono la semplicità, immediatezza.
Il punteggio si ottiene dalla moltiplicazione di 3 valori:

  1. Impact: quale impatto porta la User Story sulle metriche che stai cercando di migliorare (per es. sul conversion rate).
  2. Confidence: quanto è fiducioso il team che la User Story avrà un impatto e quanto è sicuro di essere in grado di svilupparla.
  3. Ease quanto è facile/veloce rilasciare. È la stima del tempo e numero di risorse richieste per mandare in produzione la User Story. 

Un esempio pratico di ICE Score per definire le priorità di prodotto.

Facciamo finta che tu sia il Product Manager per un Social Network e il tuo obiettivo sia 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.

Un esempio pratico di ICE Score.
Esempio di Pagina Profilo. Autore AomaF – Dribble

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 molte 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). Non abbiamo dati per stimare l’impatto ma immaginiamo che gli utenti saranno più stimolati a condividere la pagina avendo dei bottoni dedicati. Sappiamo anche che una condivisione può portare fino a 10 visite alla pagina.

Come stabilire le priorità di sviluppo prodotto tra queste User Story?

Partiamo attribuendo un punteggio a ciascuna delle 3 variabili dell’ICE Score per ogni User Story:

  • Ottimizzazione SEO pagina profilo.
    Dai dati visti sopra (+30% utenti che arrivano da Google Search) sappiamo che l’impatto può essere importante, attribuiamo quindi un valore di impatto alto (7). Potendo fare un confronto con altre aree del sito abbiamo anche una ragionevole certezza che facendo tale modifica vedremo dei risultati positivi. L’ottimizzazione SEO è inoltre un’attività che abbiamo già fatta in passato, il team sa quindi 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, richiede tante sotto-attività ma tutte con poca complessità, inseriamo un 5 per la variabile Ease.
  • Funzione Condividi via mail 
    Su questa funzione non abbiamo molti dati sul potenziale impatto, non possiamo di certo aspettarci crescite esponenziali in quanto l’aumento di visualizzazioni (la nostra metrica di partenza) dipende da 2 azioni: l’invio della mail da parte di un utente e il click sul link nella mail da parte del ricevente. Meglio tenerci bassi sulle aspettative d’impatto: 2.
    La confidence sull’impatto è anch’essa bassa in quanto non abbiamo nessun dato o riferimento che possiamo usare, anche per questa variabile inseriamo un 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à.
    In base all’esperienza e al 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
    Qui valgono le stesse considerazioni sull’impatto fatte per la funzione Condividi via mail, ma ogni condivisione social è visibile da più persone, inseriamo quindi un impatto doppio: 4.
    Dall’esperienza in altri progetti possiamo essere abbastanza sicuri sull’impatto e 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.

Ecco la tabella con il risultato dell’analisi

Calcolatore ICE Score per determinare le priorità di sviluppo prodotto.
Calcolatore ICE Score per determinare le priorità di prodotto. Scarica la tabella.

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.

Calcolatore ICE Score su Google Sheet.

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!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *