Aprile 13, 2020 - di Marco Imperato
In questo post approfondirai le tue conoscenze sul Product Backlog, il suo significato e come per te sarà una risorsa fondamentale nella gestione dei tuoi prodotti.
Abbiamo già affrontato e sfiorato l’argomento nei post sulle User Story, sulla metodologia Agile Scrum, e sulle differenze tra Scrum e Kanban, ma in questo post andrò più a fondo rispondendo anche alle domande più frequenti che mi vengono poste durante i Product Training in Azienda e il Master in Digital Product Management.
L’obiettivo di questo post è darti una comprensione chiara e approfondita del tuo principale strumento di lavoro nella gestione delle priorità e degli input riguardanti il tuo prodotto
Ecco cosa troverai in questo post:
Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 100 pagine su Agile, Team Cross-funzionale, Scrum/Kanban, Backlog, etc. ti presento 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.
Scarica Gratis Agile Starter KitIl Product Backlog è una lista ordinata di tutto ciò che deve essere, o vorresti che venisse, fatto per il tuo prodotto.
Devi considerarla come una sorta di lista dei desideri in cui sai già da subito che solo una piccola parte di quello che c’è nel Backlog potrà effettivamente essere fatto.
Qui di seguito trovi alcune peculiarità del Backlog (se alcune cose non ti saranno chiare abbi fede, i dubbi ti si scioglieranno procedendo nella lettura).
Il product Backlog è del Product Owner. La parola inglese “own” (possiede) rende meglio l’idea, nel senso che uno dei compiti fondamentali del PO è quello di mantenere e aggiornare costantemente il Product Backlog.
Dopo tutto il Product Backlog rappresenta il futuro del Prodotto stesso, per cui ha molto senso che sia chi porta avanti giornalmente il progresso del prodotto, e l’impatto sulle metriche, ad averne la responsabilità.
Abbiamo già affrontato la differenza tra product manager e product owner, e in questo caso visto che parliamo del framework Scrum, ci riferiremo al Product Owner.
Gli stakeholder, il team e il PO tutti contribuiscono al popolamento e arricchimento della lista.
Il Product Backlog di base contiene quattro tipi di elementi:
Il criterio più importante che devi tenere a mente, ed è importante ripeterlo, è che qualsiasi cosa sia presente nel backlog deve sempre aggiungere valore all’utente del tuo prodotto.
Come avrai visto è super importante che tutto ciò che consuma lavoro al team stia nel backlog.
Conosci il detto “la coperta è corta” o “la coperta è sempre quella”?
Ecco quando hai un team già allocato a un prodotto, sia come tempi che come risorse, il Backlog è la coperta. Niente trucchetti, favori o sensi di colpa: se pensiamo che una cosa sia importante e vada fatta deve sempre passare dal backlog. Capirai ancora meglio perchè tra qualche riga
Ora, con tutti questi elementi che si aggiungono continuamente al Backlog come si fa a mantenerlo ordinato?
La risposta è semplice: come Product Owner devi dedicare parte del tuo tempo al Backlog Grooming o Backlog Refinement ovvero ad assicurarti che il Backlog contenga gli elementi corretti, che siano prioritizzati e che gli elementi in cima alla lista abbiano il livello di dettaglio necessario per passare in Delivery ( se usi Kanban) o in Sprint Backlog (se usi Scrum).
Puoi lavorare sul Backlog da solo, con parte del team o con il team intero, in base alle esigenze, e queste sono alcune attività (prese da Agile Alliance):
La pesatura delle storie e dei vari elementi è stata una delle cose più strane e allo stesso divertenti che ho scoperto quando ho iniziato a usare Agile tanti anni fa.
Dal mio punto di vista è una delle procedure che meglio rappresenta la democratizzazione introdotta da Agile.
In questo post non andremo nei dettagli del processo di Estimation o pesatura delle storie, ma sappi che quando vedrai degli sviluppatori riuniti intorno a un tavolo, con delle carte in mano, che pronunciano numeri, senza un senso apparente, probabilmente ti troverai davanti a una Estimation.
In sintesi l’Estimation è una procedura svolta dal Team e che ha l’obiettivo di assegnare un punteggio che rappresenti la complessità della Storia che si ha davanti. Più alto è il punteggio, espresso in story point, più sarà difficile sviluppare quella funzionalità.
Il peso di ogni storia è un elemento essenziale.
Se immagino solo il valore che quella funzionalità potrebbe portare all’utente, ma non conosco il costo che devo sostenere per vederla sviluppata come faccio a decidere se dargli priorità o meno rispetto al milione di altre cose che potrei fare?
Se il product backlog è la “Nostra lista dei desideri”, lo sprint Backlog invece è quel “pezzo di backlog” che si intende portare in sprint per raggiungere l’obiettivo concordato.
Come avrai già letto, questo passaggio avviene durante lo Sprint Planning, un meeting che avviene all’inizio di ogni sprint, il cui obiettivo è quello di individuare gli Item su cui focalizzarsi durante la sprint, suddividerli poi in Task per poter iniziare il lavoro dal giorno successivo.
Questa procedura va fatta in Team!
Il fatto che il Product Owner possieda (owns) il Backlog, non vuol dire che sarà solo e soltanto lui a decidere cosa farci, il contrario!
E’ nella natura stessa di Agile e dei suoi principi che sia il team a decidere cosa portare in Sprint e su cosa impegnarsi.
Per comprendere ancora meglio come funziona e come usare il product Backlog ho creato un esempio che puoi anche usare come template di partenza.
Per comodità ho utilizzato come riferimento un prodotto che tutti conosciamo e usiamo abitualmente. Il prodotto a cui mi riferisco è Google Slides, il tool di Google per creare e condividere presentazioni online, e ovviamente si tratta di un esempio super semplificato in uno stadio del prodotto indefinito.
[Puoi accedere al template Del Product Backlog da questo link. Mi raccomando fai una copia del documento e usalo come preferisci, ma non chiedermi la possibilità di modificarlo]
L’obiettivo è quello di aiutarti a capire come il Product Backlog può essere utilizzato non quello di sviluppare Google Slides :).
Ho implementato il Product Backlog su Google Spreadsheet per comoditá. Se ti può interessare trovi a fine post alcuni dei tool più diffusi.
Ecco le colonne a cui mi riferisco nel template e il perché le ho inserite:
E’ il numero dell’Item che aggiungi. L’ordine è progressivo. Avere un ID è importante soprattutto per avere sempre tutti chiaro l’Item a cui ci si riferisce. La comunicazione nel lavoro in team è l’elemento fondamentale.
E’ il Nome del Task che si vuole portare in sviluppo, in base al tipo di elemento può essere espresso sotto forma di User Story, o altro.
Sebbene gli Item nel backlog siano prioritizzati dall’alto (Max priorità) verso il basso (Min priorità), non è detto che lo siano sempre, in qualsiasi momento. Inoltre la priorità dipende sempre dal “peso” di ciascun Item, che non sempre è possibile stimare quando l’Item viene aggiunto. Assegnare una priorità è molto comodo e ci fa risparmiare tanto tempo soprattutto su Spreadsheet utilizzando la funzione “order by “ per la colonna.
In questo caso troverai User Story, Epic, Bug, Tech Task, Spike, Discovery, da assegnare in base alla tipologia dell’Item.
La dipendenza è un concetto fondamentale ed è di grande utilità in fase di PLanning e scelta della priorità. Spesso sei quasi costretto a fare una cosa prima delle altre, anche se non ha un impatto immediato, semplicemente perchè da quella ne dipendono tante altre. Identificare le dipendenze ti aiuta sin da subito a ragionare in modo integrato con il Team.
ovvero il peso attribuito dopo l’Estimation.
In questo caso ipotizzo che lavorino 3 team sul prodotto a cui casualmente ho assegnato nomi di supereroi (Catwoman, Batman, Hulk). Puoi sostituire Team con Area, persone, etc.
Più il task è in alto più deve essere dettagliato, quindi per alcune storie si passa alla definizione degli Acceptance Criteria, ovvero il più basso livello di dettaglio che abbiamo a disposizione. In altri casi si aggiungono delle note per avere ulteriori informazioni che potrebbero tornare utili.
Mi sono fermato qui perchè più andrai avanti più potrai aggiungere quello che ritieni più opportuno come il nome del Po che ha ” aperto” la task, lo Status, etc.
Il fatto che il Product Backlog sia una lista onnicomprensiva del futuro del tuo prodotto non vuol dire che qualsiasi richiesta da parte di chiunque potrà farne parte.
E’ molto importante, ma già ne abbiamo tante volte qui su Product Heroes, che sia sempre estremamente chiaro il WHY dell’Item che si vuole aggiungere, il suo allineamento con la Vision di Prodotto e il potenziale impatto sulle metriche.
Cerca di evitare di aggiungere “tutto” per comodità, per poi preoccuparti dopo del senso o meno di quell’elemento nel Backlog. Se aggiungi qualcosa ci si aspetta che a un certo punto quel qualcosa verrà fatto: negozia prima e dimostra da subito che il Backlog “ti appartiene” perché hai molto chiara la linea da seguire per il tuo prodotto.
Sono tantissimi ormai i tool che puoi utilizzare per gestire il tuo Product Backlog e in generale lo sviluppo di Prodotto, qui di seguito ti elenco i più comuni. Non vogliono essere delle recensioni.
Jira: sicuramente il più noto. Ti consiglio di utilizzarlo soltanto appena inizierai a gestire una certa complessità di prodotto. Dal mio punto di vista negli ultimi anni hanno “over deliverato” complicando un po’ la UX, ma comunque va benissimo, è super integrato con praticamente tutto quello che esiste sul Product Management..
Trello o Asana: entrambi tool di Project Management poco integrati con logiche di Sviluppo Prodotto, ma vanno benissimo per iniziare a smanettare soprattutto se usi Kanban.
Phabricator: L’ho usato per un periodo 4-5 anni fa. Molto più Dev friendly che PM friendly, ma ricordo che fosse gratuito e cmq completo e aperto ad integrazioni.
Se hai qualche dubbio, curiosità o non ti è chiaro qualcosa scrivici nei commenti. Ti rispondiamo!
Co-Founder e Amministratore di Edgemony, società che fonda nel 2020, con il duplice obiettivo di accelerare lo sviluppo del territorio siciliano grazie alle competenze digitali e aiutare aiuta le aziende italiane, e non, a estendere in Sicilia il proprio Tech Team. Crea Product Heroes a fine 2018, la prima community per Product Manager in Italia che conta 6.000 iscritti alla newsletter. Product Heroes è il punto di riferimento per chi fa prodotto, e ha aiutato fino a oggi oltre 180.000 product lovers grazie al Master in Product Management, Programmi B2B, Contenuti ed Eventi on the ground. Dal 2008 guida il dipartimento di Prodotto e Digital Media di Mosaicoon, dal giorno della creazione fino alla chiusura per fallimento 10 anni dopo.
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management
3 replies on “Il Product Backlog: significato, esempio e template”
Massimo
Il link al template mi indirizza and un google doc con tenente l’articolo di questa pagina ma nessuno spreadsheet. E’ voluto? Grazie comunque e splendido articolo.
Marco Imperato
Grazie del commento Massimo! Adesso ho fixato e dovrebbe linkare al template “vero”. Fammi sapere se è tutto ok e grazie 1000 per i complimenti!
Massimo
Adesso tutto ok! Grazie ancora!