Guida Scrum · Artefatti e pratiche
Product Backlog in Scrum: cos'è e come gestirlo
Il Product Backlog è un elenco emergente e ordinato di ciò che serve per migliorare il prodotto. In Scrum è l'unica fonte del lavoro svolto dallo Scrum Team, e il suo impegno è il Product Goal.
Punti chiave
- Il Product Backlog è un elenco emergente e ordinato ed è l'unica fonte di lavoro per lo Scrum Team.
- Il Product Owner ne è responsabile; i Developer dimensionano gli elementi.
- Il suo impegno è il Product Goal, che dà una direzione al backlog.
- Mantenetelo breve, ordinato e affinato nella parte alta, e rimuovete gli elementi che non aggiungono più valore.
Che cos'è il Product Backlog
Il Product Backlog è uno dei tre artefatti Scrum, insieme allo Sprint Backlog e il Increment. Contiene tutto ciò che lo Scrum Team ritiene attualmente possa aggiungere valore al prodotto: nuove funzionalità, modifiche, correzioni, lavoro tecnico, ricerche ed esperimenti.
- Emergente: non è mai completo. Gli elementi vengono aggiunti, modificati e rimossi man mano che il team e gli stakeholder imparano.
- Ordinato: gli elementi hanno un ordine chiaro, così tutti possono vedere su che cosa si lavorerà dopo. La Guida Scrum 2020 dice ordinato anziché prioritizzato, perché l'ordine può riflettere valore, rischio, dipendenze e apprendimento oltre alla priorità.
- Unica fonte di lavoro: se lo Scrum Team ci lavorerà, deve essere visibile nel Product Backlog.
- Uno per prodotto: più Scrum Team che lavorano sullo stesso prodotto condividono un unico Product Backlog e un unico Product Owner.
Chi è responsabile del Product Backlog
Il Product Owner è responsabile dell'efficace gestione del Product Backlog. Secondo la Guida Scrum 2020 ciò comprende:
- Sviluppare e comunicare esplicitamente il Product Goal.
- Creare e comunicare chiaramente gli elementi del Product Backlog.
- Ordinare gli elementi del Product Backlog.
- Assicurare che il Product Backlog sia trasparente, visibile e compreso.
Il Product Owner può chiedere ad altri di svolgere parte di questo lavoro, ma ne resta responsabile. I Developer che svolgeranno il lavoro sono responsabili del dimensionamento degli elementi, e lo Scrum Master aiuta il Product Owner a trovare tecniche efficaci per la gestione del backlog. Chiunque voglia modificare il Product Backlog deve convincere il Product Owner.
Il Product Goal
Il Product Goal descrive uno stato futuro del prodotto verso cui lo Scrum Team pianifica. Si trova nel Product Backlog, e il resto del Product Backlog emerge per definire ciò che lo realizzerà. Il team dovrebbe raggiungere o abbandonare un Product Goal prima di affrontare il successivo.
| Livello | Impegno | Esempio |
|---|---|---|
| Product Backlog | Product Goal | I clienti possono gestire l'intero account online senza chiamare l'assistenza |
| Sprint Backlog | Sprint Goal | I clienti possono scaricare le fatture passate in PDF |
| Increment | Definition of Done | Codice revisionato, testato, accessibile e distribuito in produzione |
Che cosa contiene un elemento del Product Backlog
La Guida Scrum non prescrive un formato. Gli attributi variano in base al dominio di lavoro, ma la maggior parte dei team registra:
| Attributo | Scopo |
|---|---|
| Descrizione | Che cosa serve e perché; spesso scritto come user story |
| Ordine | La sua posizione rispetto agli altri elementi |
| Dimensione | Una stima dei Developer, ad esempio in story point |
| Criteri di accettazione | Condizioni che confermano che l'elemento fa ciò che deve |
| Valore o motivazione | Il risultato o beneficio atteso |
| Note e link | Design, ricerche, dipendenze o epic |
Gli elementi in cima sono piccoli, chiari e dettagliati. Quelli più in basso possono essere più grandi e vaghi, perché i dettagli aggiunti troppo presto vanno spesso sprecati. Gli elementi che possono essere Done entro uno Sprint sono considerati pronti per essere selezionati nello Sprint Planning.
Come gestire un Product Backlog, passo dopo passo
- Mettete per iscritto il Product Goal e condividetelo con il team e gli stakeholder.
- Raccogliete idee, richieste e lavoro noto come elementi, senza preoccuparvi per ora dei dettagli.
- Ordinate gli elementi considerando valore, rischio, costo, dipendenze e ciò che il team deve imparare.
- Affinate regolarmente la parte alta del backlog, in modo che gli elementi per i prossimi uno o due Sprint siano chiari e dimensionati; vedi backlog refinement.
- Usate la Sprint Review per ispezionare l'avanzamento con gli stakeholder e adattare il backlog.
- Rimuovete gli elementi che non supportano più il Product Goal, così il backlog resta breve e utile.
- Monitorate l'avanzamento verso il Product Goal con un burnup chart o una previsione; vedi Metriche Scrum.
Esempio pratico: ordinare un piccolo backlog
Il Product Owner di un servizio di prenotazione online ha il Product Goal "I clienti possono prenotare e modificare gli appuntamenti senza telefonarci". I Developer hanno dimensionato gli elementi. Il Product Owner li ordina soppesando il valore rispetto a dimensione e rischio:
| Ordine | Elemento | Dimensione (punti) | Motivo della sua posizione |
|---|---|---|---|
| 1 | Prenotare un appuntamento online | 8 | Centrale per il Product Goal; nient'altro è utile senza di esso |
| 2 | Email di conferma dopo la prenotazione | 3 | Alto valore, piccolo, riduce le mancate presentazioni |
| 3 | Modificare o annullare una prenotazione | 5 | Riduce direttamente le telefonate |
| 4 | Spike: integrazione con il fornitore del calendario | 2 | Riduce il rischio prima dell'elemento 5 |
| 5 | Sincronizzare le prenotazioni con i calendari del personale | 8 | Di valore, ma dipende da ciò che emerge dallo spike |
| 6 | Codici sconto fedeltà | 13 | Non necessario per il Product Goal attuale |
Se la velocity è di circa 15 punti, gli elementi da 1 a 3 (16 punti) superano di poco uno Sprint, quindi il team potrebbe pianificare gli elementi 1 e 2 più lo spike, e affrontare l'elemento 3 nello Sprint successivo. L'elemento 6 può essere rimosso o accantonato fino a un Product Goal successivo.
Product Backlog vs Sprint Backlog
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Contenuto | Tutto ciò che potrebbe migliorare il prodotto | Sprint Goal, elementi selezionati e un piano |
| Accountable (responsabile finale) | Product Owner | Developer |
| Impegno | Product Goal | Sprint Goal |
| Orizzonte temporale | L'intera vita del prodotto | Uno Sprint |
| Cosa cambia | Ogni volta che il Product Owner riordina o aggiunge elementi | Ogni giorno, man mano che i Developer imparano |
Errori comuni
- Un backlog che continua solo a crescere. Centinaia di elementi vecchi nascondono ciò che conta. Eliminate o archiviate gli elementi che non servono più al Product Goal.
- Più backlog per un unico prodotto. Backlog separati per team rendono impossibile ordinare il lavoro sull'intero prodotto.
- Tutto è "alta priorità". L'ordine è una sequenza rigorosa, non un insieme di etichette.
- Troppi dettagli troppo presto. Le specifiche dettagliate per elementi lontani mesi vengono di solito riscritte.
- Il Product Owner lavora da solo. Il refinement funziona meglio come collaborazione con i Developer e gli stakeholder.
- Nessun Product Goal. Senza di esso, il backlog diventa un elenco di richieste anziché un piano per creare valore.
Modelli gratuiti per questo argomento
Domande frequenti
Che cos'è un Product Backlog in Scrum?
È un elenco emergente e ordinato di ciò che serve per migliorare il prodotto, ed è l'unica fonte di lavoro per lo Scrum Team. Il suo impegno è il Product Goal.
Chi è responsabile del Product Backlog?
Il Product Owner ne è responsabile. Altri possono contribuire e può essere chiesto loro di svolgere parte del lavoro, ma è il Product Owner a decidere l'ordine.
Chi può aggiungere elementi al Product Backlog?
Chiunque può suggerire elementi, e in molti team i Developer li aggiungono direttamente. Il Product Owner resta responsabile del contenuto e dell'ordine.
Qual è la differenza tra un Product Backlog prioritizzato e uno ordinato?
Assegnare priorità spesso significa etichettare gli elementi come alta, media o bassa. Ordinare significa mettere ogni elemento in un'unica sequenza, che può riflettere valore, rischio, dipendenze e apprendimento.
Che rapporto c'è tra il Product Goal e il Product Backlog?
È l'impegno associato al Product Backlog: uno stato futuro del prodotto verso cui lo Scrum Team pianifica. Il team lavora su un Product Goal alla volta.
Quanto dovrebbe essere grande un Product Backlog?
Non esiste una regola. Un backlog troppo lungo per essere letto e ordinato diventa difficile da gestire, quindi molti team mantengono elementi dettagliati solo per pochi Sprint e conservano il resto come elementi più grandi e sommari.
Gli elementi del Product Backlog devono essere user story?
No. La Guida Scrum non prescrive un formato. Le user story sono diffuse, ma gli elementi possono essere anche bug, attività tecniche, esperimenti o semplici descrizioni.
Chi stima gli elementi del Product Backlog?
I Developer che svolgeranno il lavoro sono responsabili del dimensionamento. Il Product Owner può aiutarli a comprendere gli elementi e i compromessi.
Quando un elemento del Product Backlog è pronto?
La Guida Scrum afferma che gli elementi che possono essere Done entro uno Sprint sono considerati pronti per essere selezionati nello Sprint Planning. Alcuni team aggiungono una Definition of Ready facoltativa.
Più team possono condividere un unico Product Backlog?
Sì. In Scrum un prodotto ha un unico Product Backlog e un unico Product Owner, anche quando più team ci lavorano.
Il Product Backlog è la stessa cosa di un piano di progetto?
No. È un elenco in evoluzione per il prodotto anziché un piano fisso, anche se può essere usato insieme a previsioni e a un piano di rilascio.
Quali strumenti posso usare per un Product Backlog?
Qualsiasi cosa, da un foglio di calcolo o post-it a strumenti come Jira o Trello. Vedi Strumenti software per Scrum.