Guida Scrum | 40. Coltivazione del Product Backlog

Il nutrimento del Product Backlog è uno dei compiti primari di un Product Owner. Il processo di nutrimento include la formulazione, il dettaglio e l'aggiunta di nuove User Story al Product Backlog. Tuttavia, il più importante dei compiti di nutrimento è garantire che le voci inserite nel Backlog siano nell'ordine giusto, cioè abbiano la priorità.

Consolidamento del Product Backlog – sommario:

1. introduzione
2. Scopo del mantenimento del Product Backlog
3. Errori nella manutenzione del Product Backlog
4. Manutenzione del backlog rispetto alle metriche utilizzate in Scrum
5. Riepilogo

introduzione

Il Product Backlog è uno degli Artefatti di Scrum. Contiene un elenco prioritario del lavoro necessario per creare un prodotto. In altre parole, è un elenco di User Story necessarie per raggiungere l'obiettivo del prodotto. Puoi trovare una descrizione dettagliata di cosa sono le User Story in questo articolo. Ed ecco i dettagli sulle caratteristiche e su come mantenere il Product Backlog.

Il nutrimento del Product Backlog ha anche i seguenti nomi:

• Priorità degli arretrati,
• Affinamento dell'arretrato,
• Ridimensionamento dell'arretrato.

Scopo del mantenimento del Product Backlog

Il Product Owner gestisce il Product Backlog. Le abilità chiave includono la definizione delle priorità delle attività man mano che si avvicina la data di scadenza. Questo perché l'obiettivo del nutrimento del Product Backlog è assicurarsi che le funzionalità del Prodotto abbiano il più alto valore di business, ovvero quelle più essenziali dal punto di vista del Cliente, siano in cima alla lista delle cose da fare. E la loro descrizione è chiara e dettagliata in modo che la loro implementazione possa iniziare proprio nel prossimo Sprint.

Il Product Backlog può essere aggiornato quotidianamente, se necessario. Il Product Owner può aggiungere nuove User Story al Product Backlog dopo aver parlato con gli Stakeholder e il Team di sviluppo, oppure traendo conclusioni e riformulando le User Story già scritte nel Product Backlog.

L'aggiornamento obbligatorio del Backlog è una delle attività svolte durante lo Sprint Review. Abbiamo descritto questo processo in dettaglio in questo articolo. Solitamente, durante questo incontro, lo Scrum Team discute non solo i compiti da completare nel prossimo Sprint. Inoltre specifica preliminarmente le User Story e la loro implementazione nei prossimi due o tre Sprint. Questo modo di fare le cose consente allo Scrum Team e alle sue attività di avere una visione più ampia della direzione a lungo termine. Consente di pensare ai compiti attualmente in corso dalla prospettiva del loro sviluppo negli Sprint successivi.

Errori nella manutenzione del Product Backlog

Uno dei problemi più comuni per quanto riguarda il nutrimento del Product Backlog è quello di consentirgli di espandersi in modo incontrollabile. Questo perché mentre si lavora sul Prodotto, compaiono spontaneamente varie funzionalità e compiti aggiuntivi proposti sia dagli Stakeholder che dai membri dello Scrum Team. Pertanto, limitare la crescita dell'ambito del Product Backlog (scope creep) è uno dei compiti più importanti svolti dal Product Owner. Gli errori più comuni commessi dai Product Owner riguardano:

1. Deviare dall'obiettivo del prodotto : aggiungere troppe idee al Product Backlog oltre l'obiettivo del prodotto di base non è una buona pratica, poiché ne riduce notevolmente la leggibilità. È meglio raccogliere idee per funzionalità aggiuntive in un documento separato.
2. Duplicazione del contenuto – inserendo idee ripetute o molto simili da diversi Stakeholder nel Backlog – prima di aggiungere un'altra voce al Backlog, il Product Owner dovrebbe assicurarsi che la nuova voce non duplichi nessuna di quelle esistenti.
3. Mancanza di una prospettiva più ampia : dovresti ordinare le voci del Product Backlog in base al loro valore rispetto all'obiettivo del prodotto. Tuttavia, tieni presente che la definizione delle priorità dovrebbe tenere conto dei successivi Sprint in modo che le attività eseguite in un determinato Sprint siano perfettamente collegate sia allo Sprint precedente che allo Sprint immediatamente successivo

Non puoi evitare errori di questo tipo. Tuttavia, la consapevolezza del loro verificarsi può rendere il Product Owner più cauto nell'aggiungere nuove User Story al Product Backlog per trovare il giusto equilibrio. Questo perché è anche un errore tagliare troppo il Backlog ed eliminare voci che contengono attività simili che differiscono. Ad esempio, la descrizione di funzionalità del prodotto simili che differiscono in modo significativo nell'applicazione.

Manutenzione del backlog rispetto alle metriche utilizzate in Scrum

Il Product Backlog contiene una descrizione del lavoro rimanente durante tutto il progetto. Tuttavia, solo un Backlog aggiornato e regolarmente alimentato può stimare con precisione il rapporto tra la quantità di lavoro completata e il totale. Per rappresentare la quantità di lavoro completato, dovresti applicare il Burndown Chart, di cui abbiamo parlato in questo articolo.

Un'altra metrica popolare per descrivere il lavoro di Scrum Team è la Velocity. Puoi misurarlo confrontando il numero di voci del Product Backlog convertite in Incremento durante un singolo Sprint. Abbiamo descritto Velocity in modo più dettagliato in questo articolo.

Riepilogo

Il Product Owner esegue il Product Backlog Nurturing. Quando il Product Backlog è ben mantenuto, lo Scrum Team ha una visione chiara del lavoro che resta. Può anche avere una prospettiva più ampia e lungimirante di come appare il percorso verso l'obiettivo del prodotto. Questo è il motivo per cui il Product Owner deve assicurarsi che le User Story incluse nel Product Backlog siano in ordine di priorità per il completamento. E anche che le attività da completare nei prossimi Sprint sono descritte nei minimi dettagli.

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