Guida Scrum | 18. Cos'è il Product Backlog?

Il Product Backlog è l'unica fonte di attività svolte dallo Scrum Team. È un elenco di funzionalità e miglioramenti del prodotto pianificati. La sua forma è mutevole e non tutte le attività incluse nel Product Backlog saranno completate. Si evolve durante le discussioni con gli stakeholder. Inoltre è costantemente migliorato. Significa che più vicino alla scadenza diventa un compito più dettagliato.

Cos'è il Product Backlog? - sommario:

1. introduzione
2. Cosa contiene il Product Backlog?
3. La forma del Product Backlog
4. Miglioramento del Product Backlog
5. Riepilogo

introduzione

Il Product Backlog è il più grande degli Scrum Artifact. Riflette lo stato del lavoro su un prodotto in relazione all'obiettivo del prodotto. D'altra parte, quando il lavoro su un Prodotto è completato, il suo Backlog diventa un elenco completo dei compiti svolti dallo Scrum Team per creare il Prodotto. Tuttavia, non contiene soluzioni tecniche dettagliate.

Cosa contiene il Product Backlog?

Il Product Backlog viene creato durante gli incontri del Product Owner con gli Stakeholder. Il Product Owner è l'unico proprietario e la persona responsabile di questa fonte di compiti.

Il linguaggio commerciale caratterizza le voci nel Product Backlog. In altre parole, descrivono il valore del Prodotto dal punto di vista degli Stakeholder.

Le descrizioni delle attività incluse nell'elenco delle attività richiedono coerenza e chiarezza. Contengono funzioni e miglioramenti del Prodotto solitamente presentati sotto forma di User Story a cui dedichiamo una voce separata. Qui menzioneremo solo che si tratta di descrizioni di funzionalità parziali del prodotto che rispondono alle domande sui seguenti problemi:

• L'ambito delle modifiche al prodotto
• Lo scopo di modificare il Prodotto
• Il tipo di utente per il quale viene visualizzata questa modifica

La forma del Product Backlog

L'ordine delle attività incluse nel Product Backlog cambia con lo sviluppo del Prodotto. Mentre ci lavora, lo Scrum Team ne modella e migliora le funzionalità. Incontrando ostacoli, le sue azioni attuate consentono a tutti di pensare e definire future soluzioni adeguate, e anche queste cambieranno di conseguenza per ulteriori ostacoli imprevisti. Pertanto, non esiste un ordine chiaro e definito delle azioni, tutto è mutevole. Il miglioramento del Product Backlog è finalizzato al suo continuo aggiornamento e preparazione per le attività successive. Per questo motivo è continuo.

Le attività con una scadenza lontana sono in genere insiemi generici e grandi. La loro descrizione non contiene dettagli, ma solo uno schema di funzionalità che dovrebbe essere realizzato. È anche possibile trovare attività tra di loro che non termineranno mai.

Le voci nel Product Backlog possono presentare soluzioni alternative. E anche le idee del Cliente che possono diventare obsolete, non redditizie o per altro motivo non entrano mai nella fase di attuazione. Ecco perché il Product Backlog viene talvolta chiamato scherzosamente la “lista dei desideri del cliente”.

Un altro motivo per i cambiamenti nella forma del Product Backlog è la ridefinizione delle soluzioni. A volte si scopre che un certo problema è già stato risolto durante la creazione di un'altra funzionalità del prodotto. Oppure la funzionalità prevista è diventata ridondante a causa di modifiche in altre soluzioni.

Una delle attività di base durante il miglioramento del Product Backlog è la divisione in parti delle attività contenute nel Product Backlog. Grazie a ciò, lo schema generale della funzionalità viene presentato sotto forma di unità più piccole, più dettagliate e definite con precisione.

Le attività progettate per una più stretta attuazione diventano più dettagliate. Diventano anche più piccoli, contenenti dettagli di soluzioni. I dettagli emergono durante lo sviluppo del prodotto. E grazie alla conoscenza dello stato attuale del Prodotto e delle attuali aspettative degli Stakeholder, il Product Owner integra le attività imminenti con la loro descrizione, ordine e dimensione. Quindi, seleziona le attività meglio descritte per il prossimo Sprint Backlog.

Miglioramento del Product Backlog

Mentre lavora su un prodotto, il Product Owner modifica e dettaglia il Product Backlog in collaborazione con il Team di sviluppo. Seguendo i suggerimenti del Product Owner, durante lo Sprint Planning il team seleziona le funzionalità da implementare dal Product Backlog. Vengono quindi spostati nello Sprint Backlog e suddivisi in attività da completare. Le attività spostate nello Sprint Backlog sono descritte nel linguaggio tecnico, che è il più utile per gli Sviluppatori.

La dimensione dell'attività è una metrica importante dal punto di vista del team di sviluppo. La sua corretta stima diventa particolarmente critica quando si selezionano le User Story dal Product Backlog allo Sprint Backlog.

Il Team di sviluppo impara nel tempo a stimare correttamente il tempo e l'impegno necessari per completare una specifica User Story. Questo è espresso in giorni, ore uomo o Story Point e fornisce una stima di un valore chiamato Team Velocity.

Riepilogo

Il Product Backlog è un elenco continuamente migliorato di attività che portano all'obiettivo del prodotto. Il contenuto del Product Backlog è solitamente espresso sotto forma di User Story. E più breve è il tempo rimanente per completare un'attività, il:

• La descrizione del lavoro è più dettagliata
• L'ambito del compito è più piccolo
• L'ambito del compito è meglio definito

Lo Scrum Team si occupa dei compiti. Il Product Owner gestisce e modifica il Product Backlog.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog