Product Backlog: cos’è e come usarlo

Scopriamo un altro elemento fondamentale per mettere in pratica la filosofia Agile: il Product Backlog

Che cos’è il Product Backlog?

Il Product Backlog è un elenco prioritario di elementi di lavoro o caratteristiche che si ritiene debbano essere completati per avanzare nello sviluppo di un prodotto.

Il product Backlog è strettamente connesso all’implementazione pratiche della filosofia Agile.

Nei framework agili come Scrum e Kanban, il backlog funge da unica fonte di verità (single source of truth) per quanto riguarda il lavoro del team di sviluppo.

1. Scrum: In Scrum, il backlog è dinamico, con l’aggiunta, la rimozione o la ridefinizione delle priorità in risposta alle mutevoli esigenze dei clienti o alle richieste del mercato. È di proprietà del proprietario del prodotto (Product Owner), che lo aggiorna e lo perfeziona continuamente.
2. Kanban: In Kanban non esiste un concetto rigido di backlog di prodotto, ma può esistere un elenco prioritario di caratteristiche o attività. Questi compiti scorrono nel sistema senza iterazioni temporali, fornendo un approccio continuo e flessibile allo sviluppo del prodotto.

Il Product Backlog può includere:

1. Titolo: nome descrittivo dell’attività; i puristi consigliano iniziare con un verbo che rappresenti un’azione (ad esempio “design”, “develop”, “implement”).
2. Task Priority: l’urgenza, rilevanza, dell’attività.
3. Target Sprint: indica in quale sprint ideale il task vada collocato.
4. Story point: eventuale stima dell’effort attuativo necessario per portare a termine l’attività.
5. User Stories: Piccole unità funzionali dal punto di vista dell’utente.
6. Technical Debt Items: Tutte le tematiche afferenti al refactoring e al debito tecnico.
7. Bugs: Difetti del prodotto.
8. Epics: Grandi caratteristiche generali suddivise in storie più piccole.

Storia del Product Backlog

Il concetto di product backlog è nato con Scrum (interessato a Scrum? Leggi la nostra super guida qui), uno dei framework agili più popolari.

Scrum è nato nel 1993 grazie a Ken Schwaber, Jeff Sutherl, John Scumniotales e Jeff McKenna.

Scrum è nato come alternativa al tradizionale sviluppo a cascata (“waterfall”), fornendo un approccio iterativo e incrementale alla gestione di progetti complessi.

Nel tempo, il Product Backlog si è evoluto come entità dotata di propria dignità all’interno del più ampio ecosistema Agile.

1. Metodologie pre-Agile: Le metodologie di sviluppo tradizionali, come quella a cascata, si concentrano su una pianificazione a monte e su lunghi documenti di requisiti. Non esiste un “backlog”, ma piuttosto una specifica completa dei requisiti. Tale documentazione è per sua natura intrinseca immutabile; eventuali add-on vengono gestiti come change-request (CR) o sviluppi incrementali.
2. Primi anni di Agile: il concetto di Product Backlog è stato introdotto per garantire che il team disponesse di un elenco vivo e prioritario, che permettesse la flessibilità di modificare le attività in base al feedback degli utenti e in base anche all’evoluzione e maturità del progetto. Non è triviale infatti definire ex ante tutte le feature di un prodotto.
3. Agile moderno (Scrum e Kanban): I Product Backlog sono diventati un artefatto centrale in Scrum e Kanban, consentendo ai team di pianificare in modo iterativo o continuo le feature di prodotto, a seconda del framework.

Oggi il Product Backlog sta vivendo una fase fortemente destrutturata che ne vede l’utilizzo pratico anche fuori da contesti formalmente collegati ad Agile.

In conseguenza di una sempre maggiore adozione della filosofia Agile, le sue componenti pratiche (elementi dei framework) vengono adottate anche in progetti gestiti secondo metodi tradizionali, generando ibridi in continua evoluzione.

Questo testimonia il grado di vivacità di Agile, che potremmo dire ricorsivamente ha fatto propri i suoi stessi dettami, modificandosi iterativamente e adattandosi al contesto.

Il Product Backlog per il team Agile

Sebbene il Product Backlog sia gestito principalmente dal Product Owner, diversi ruoli interagiscono con esso:

1. Product Owner: Il principale responsabile del Product Backlog. È responsabile della definizione delle priorità, della chiarificazione dei requisiti e dell’allineamento con la visione del prodotto. In Scrum, questo ruolo assicura che il Product Backlog rifletta le esigenze del cliente e del business.
2. Scrum Master: Facilita il processo di perfezionamento e assicura che il team aderisca ai principi agili. Lo Scrum Master aiuta a rimuovere gli ostacoli che potrebbero impedire l’avanzamento delle attività. Interviene specificatamente per verificare la correttezza formale del Product Backlog.
3. Team di sviluppo: Il team (sviluppatori, tester, designer, ecc.) utilizza il Product Backlog per guidare il proprio lavoro durante gli sprint. Sono responsabili della stima delle voci del backlog, del feedback tecnico e della suddivisione delle storie in attività. Inoltre sfruttano il backlog come elemento di compensazione per inserire eventuali feature e funzionalità sorte in via incrementale.
4. Stakeholder: Sono tipicamente diversi referenti aziendali, ossia dell’entità committente del prodotto. Possono fornire input sulla prioritizzazione del backlog attraverso il Product Owner. Non interagiscono direttamente con il product Backlog, ma ne influenzano la direzione in base alle esigenze aziendali.
5. Designer UX: Spesso lavorano con le voci del backlog per progettare l’esperienza dell’utente per le funzionalità, allineando le storie dell’utente con i requisiti funzionali ed estetici.
6. Project Manager: un ruolo più canonico che tuttavia può esistere (o coesistere) nell’ambito progettuale e che può consultare il Product Backlog per saggiare la temperatura del progetto e stimarne una data di completamento (anche in funzione di eventuali milestone progettuali).

Vantaggi del Product Backlog

Il Product Backlog offre molti vantaggi ai team agili; possiamo spingerci oltre e affermare che sia una vera e propria necessità.

Senza Product Backlog infatti non avrebbero collocamento progettuale tutte le istanze incrementali, ma anche i defect, bug e esigenze di refactoring che inevitabilmente insorgono in un progetto che abbia una durata superiore a poche settimane di lifespan.

1. Trasparenza: Il backlog è un artefatto visibile e condiviso che rende chiaro a tutti i partecipanti lo stato attuale del lavoro e le attività future. Mantiene il team concentrato sulle priorità. Inoltre è condivisibile come visto poco sopra anche con figure tangenti il team core del progetto.
2. Adattabilità: Mantenendo un documento vivo, i team possono modificare rapidamente le priorità in base alle nuove informazioni disponibili, che si tratti di feedback dei clienti, cambiamenti di mercato o evoluzioni tecnologiche.
3. Concentrarsi sul valore: La definizione delle priorità delle storie ed epiche assicura che le funzionalità di maggior valore siano consegnate per prime, ottimizzando il valore del progetto. Evita anche l’insorgere di implementazioni basate su urgenze soggettive e non oggettive (ad esempio date da HiPPO)
4. Miglioramento della collaborazione: Le frequenti discussioni sul backlog favoriscono la collaborazione tra stakeholder, sviluppatori e business owner. Ad esempio, le riunioni di rifinitura del backlog assicurano che tutti comprendano e concordino sul lavoro da svolgere. Genera anche serenità verso gli stakeholder i quali sanno che le loro richieste incrementali sono puntualmente gestite.
5. Riduzione della complessità: Il Product Backlog consente ai team di suddividere le grandi funzionalità (epiche) in storie gestibili. Questo incoraggia la consegna iterativa, in cui pezzi del sistema possono essere costruiti, testati e distribuiti regolarmente. L’attività stessa di refining del backlog incentiva e ingaggia il team verso la sua riduzione.

Fasi del Product Backlog

Il backlog di prodotto si evolve attraverso diverse fasi definite formalmente.

1. Creazione iniziale: All’inizio del progetto, il Product Owner e gli stakeholder creano una serie iniziale di voci del backlog basate sulla visione di alto livello del prodotto. Spesso si tratta di Epiche o di funzionalità principali note oggettivamente.
2. Affinamento del backlog: Si tratta di un processo continuo. Il team perfezionerà e scomporrà continuamente le voci del backlog in storie più piccole e più attuabili. Le storie vengono chiarite, stimate e ridefinite in base al loro valore, alla complessità e alle dipendenze.
   L’affinamento comprende sessioni di grooming (ossia aggiornamento puntuale del backlog) in cui il Product Owner e il team discutono del lavoro imminente per garantire che le storie siano ben comprese e “pronte” (DoR, Definition of Ready) per il team per iniziare a lavorare.
3. Pianificazione dello sprint (solo Scrum): Per i team Scrum, prima di ogni sprint, il team seleziona dal backlog gli elementi a più alta priorità che si ritiene possano essere completati nello sprint. Questo elenco diventa lo Sprint Backlog.
4. Consegna continua (Kanban): In Kanban, gli elementi vengono continuamente estratti dal backlog e inseriti nel flusso di lavoro non appena il team si rende disponibile. L’attenzione si concentra sulla gestione del flusso piuttosto che sulla pianificazione in iterazioni a tempo.
5. Feedback e aggiustamenti: Dopo ogni sprint o consegna continua, il team e le parti interessate rivedono l’incremento del prodotto. Nuove intuizioni o feedback possono portare a una ridefinizione delle priorità o all’aggiunta di nuove storie.
6. Completamento o archiviazione: Gli elementi vengono completati e integrati nel prodotto, oppure archiviati se non soddisfano più gli obiettivi del prodotto.

Sebbene questo iter sia rigorosamente formalizzato nelle pratiche Agili, e specialmente in Scrum, il Product Backlog può esistere anche in declinazioni ibride gestite specialmente da team di sviluppo di modeste dimensioni. Ciò non rende il Product Backlog formalmente errato o inefficiente, ma solo diverso.

Sarebbe errato tentare di incasellare una pratica Agile in una definizione stringente riducendone l’impatto, l’efficienza o l’efficacia.

I principali errori nella gestione del Product Backlog

1. Tutto è urgente: se tutto è urgente, nulla è urgente. Il team deve essere in grado (ed avere la necessaria autorità e autorevolezza) per assegnare una priorità realistica. Un corretto backlog mostra una distribuzione normale delle priorità (dove Low e High rappresentano le code della distribuzione).
2. Descrizioni vaghe: un Product Backlog “lazy” non è solo brutto da vedere, ma anche dannoso. Se le descrizioni sono aleatorie, esse diventano fonte di incomprensioni se non di veri e propri errori in sede di sviluppo.
3. No Grooming: il Product Backlog è come una buona birra: va consumato fresco. Se è rimasto a decantare per lungo tempo, esso sarà obsoleto, fonte di errori, inadeguato. Il Product Backlog va manutenuto e aggiornato con regolarità!
4. Product Backlog lievitante: Il Product Backlog non deve diventare un rifugio per ogni sorta di capriccio o funzionalità. Un backlog lungo diverse pagine dovrebbe preoccupare e generare sorpresa nel team, che si dovrebbe mettere al lavoro per ridurlo.
5. Mancanza di consistenza e autoreferenzialità: un backlog gestito da un solo membro del team diventa un elemento soggettivo, pericoloso per il progetto. Va forza la condivisione e la challenge costruttiva al backlog come a ogni altro elemento progettuale.
6. Mancanza di chiarezza sugli ingaggi: anche se il Product Backlog potrebbe non essere rigorosamente formale, è bene che sia chiaro per il team quale sia la definizione di pronto (DoR) e di fatto (DoD). Diversamente il team potrebbe non comprendere cosa sia terminato, cosa in lavorazione, e cosa ancora completamente open.
7. Mancanza di stime: la stima rende il backlog un artefatto azionabile. Senza di esso è solo una wishlist o una to-do-list.
8. Scollamento tra business e tech: il Product Backlog deve parlare la lingua del progetto. Un backlog troppo orientato agli aspetti business piuttosto che tecnologici è foriero di mismatch tra i desideri degli stakeholder e del team di sviluppo.
9. Mancanza di feedback: il backlog deve essere costantemente aggiornato e i feedback sullo stesso devono essere richiesti con un senso di urgenza. Si diffida di task nel backlog che non sono aggiornati da mesi e non cambiano stato.
10. Backlog statico: il Product Backlog è un artefatto vivo e dinamico che evolve se non ogni giorno, sicuramente su base settimanale. Un backlog immutato, stantio, con aggiornamenti inconsistenti e vetusti, è indizio che qualcosa non sta funzionando a dovere.

Conclusioni

Il miglior modo per imparare il Product Backlog è usarlo!

Se ti serve un template, ti consigliamo Asana [Sprint Backlog Template].

Comincia subito e iscriviti alla nostra newsletter per non perdere i nostri contenuti e avere subito la guida alla gestione del debito tecnico.