Il Product Backlog: significato, esempio e template

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:

1. Cosa è il Product Backlog
2. Il Product Backlog e Il Product Owner
3. Cosa c’è nel Product Backlog
4. Cosa è il Backlog Grooming o Backlog Refinement
5. Estimation e Product Backlog
6. Product Backlog, Sprint Backlog e Task in Scrum
7. Un Esempio e un Template di Product Backlog
8. I tool più utilizzati per il Product Backlog

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.

Cosa è il Product Backlog

Il 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).

Le caratteristiche distintive del Product Backlog

• A differenza dei classici documenti di requisiti o delle liste consegnate dal Marketing o Operation il Product Backlog è un documento vivente. Va, infatti, mantenuto ogni giorno, con il cosiddetto Backlog Grooming.
  
• Non tutti gli elementi presenti nel Backlog hanno lo stesso livello di dettaglio. Più l’elemento è in alto nella lista, maggiore deve essere il livello di dettaglio.
  
  La logica dietro questo principio è molto semplice: se si ritiene che un elemento sia più importante degli altri starà più in alto nella lista e avrà maggiore priorità, maggiore priorità corrisponde alla probabilità che quell’elemento venga portato in sviluppo prima degli altri, quindi saranno necessari più dettagli possibili affinché, quando se ne presenterà l’occasione, quell’elemento possa passare nello Sprint Backlog e avvicinarsi finalmente al rilascio in produzione.

• Come vedrai più avanti, nel Backlog possono essere presenti quattro tipologie di elementi, ma tutti devono sempre aggiungere valore all’utente finale per cui il prodotto è stato pensato.
  
• Il Backlog non è una to-do-list di task specifiche, quelle verranno generate soltanto durante lo sprint planning prima di passare in sviluppo.
  
• Il Backlog è sempre prioritizzato con un livello sufficiente di dettaglio per impostare almeno una nuova Sprint.
  
• Non esiste una forma standard di rappresentazione del Backlog: può essere un foglio Excel, una colonna su Trello, il “Backlog” su Jira o dei post-it sul muro.

Il Product Backlog e Il Product Owner

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.

Cosa c’è nel Product Backlog

Il Product Backlog di base contiene quattro tipi di elementi:

• Le funzionalità sono espresse sotto forma di User Story, ovvero una breve e semplice descrizione della funzionalità che si vorrebbe avere raccontata dal punto di vista dell’utente. 
  
• I Bug, ovvero un comportamento inaspettato del Software da parte dell’utente che gli impedisce o gli rende più difficile il completamente di un obiettivo/azione.
  
  E’ importante che i Bug rientrino nel Backlog perché oltre a essere direttamente collegati alla creazione di valore, “consumano” tempo del team e quindi devono sempre essere considerati nell’allocazione delle risorse. Si fa eccezione per i bug gravi che possono passare andare direttamente in Sviluppo (Fastlane) senza passare dal backlog.
  
  [Leggi il post su come scalare la gestione dei bug se vuoi approfondire]
  
• Knowledge Acquisition, ovvero tutto ciò che devi fare per capire cosa devi fare 🙂 Non è uno scioglilingua, ma semplicemente quando fai delle cose per la prima volta devi necessariamente dedicare del tempo a delle attività di scoperta. Possono essere direttamente rivolte all’utente come interviste, realizzazione di prototipi, etc. e prendono il nome di Product Discovery. Se invece sono task prettamente tecniche prendono il nome di Spike: si scrive del codice (che poi sai che verrà buttato) per capire che tecnologia utilizzare, come fare una certa integrazione o task tecnica più complessa.
  
• Tech Task, ovvero quell’insieme di attività tecniche che devono essere fatte affinché il tuo prodotto possa vivere o in alcuni casi sopravvivere. Onestamente sono quelle cose che come Product Manager non vorresti mai fare (es: migrazione server, adattamente dopo cambio API, etc.) Perché consumano tempo ma non necessariamente aggiungono valore. Il problema è che se non fai queste cose il Debito Tecnico aumenterà a dismisura e a un certo punto lo dovrai pagare. Te lo garantisco.

Qualsiasi elemento in backlog deve aggiungere valore

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

Cosa è il Backlog Grooming o Backlog Refinement

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):

• Eliminare user story o altri elementi che non sono più rilevanti;
• Creare nuovi elementi o user story in base a nuove scoperte o nuovi bisogni;
• Riordinare gli elementi;
• Assegnare story point alle user story che devono ancora riceverle;
• Correggere il peso, in termini di story point, della user story in base a nuovi elementi scoperti;
• Suddividere le storie più grandi (Epiche) in storie più piccole se sono nella parte alta del backlog e sono troppo grandi per essere portate in sviluppo.

Estimation e Product Backlog

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?

Product Backlog, Sprint Backlog e Task in Scrum

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.

Un Esempio e un template di Product Backlog

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 :).

Come è organizzato il template del product Backlog.

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:

#ID

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.

Item

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.

Priorità

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.

Categoria

In questo caso troverai User Story, Epic, Bug, Tech Task, Spike, Discovery, da assegnare in base alla tipologia dell’Item.

Dependencies

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.

Story Point (SP)

ovvero il peso attribuito dopo l’Estimation.

Team

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.

Acceptance Criteria / Note

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.

Un ultimo consiglio finale: devi dire di NO.

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.

I tool più utilizzati per Il Product Backlog

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!

Leggi di più sul Backlog