Scrum Guide | 40. Cura del Product Backlog

La cura del Product Backlog è uno dei compiti principali di un Product Owner. Il processo di cura include la formulazione, la definizione e l’aggiunta di nuove User Stories al Product Backlog. Tuttavia, il compito più importante della cura è garantire che le voci inserite nel Backlog siano nell’ordine corretto, ovvero che diventino prioritarie.

Cura del Product Backlog – indice:

1. Introduzione
2. Scopo della cura del Product Backlog
3. Errori nella manutenzione del Product Backlog
4. Manutenzione del Backlog vs. 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 Stories necessarie per raggiungere l’Obiettivo del Prodotto. Puoi trovare una descrizione dettagliata di cosa sono le User Stories in questo articolo. E qui ci sono i dettagli sulle caratteristiche e su come mantenere il Product Backlog.

La cura del Product Backlog è conosciuta anche con i seguenti nomi:

• Prioritizzazione del Backlog,
• Raffinamento del Backlog,
• Scalabilità del Backlog.

Scopo della cura del Product Backlog

Il Product Owner gestisce il Product Backlog. Le competenze chiave includono la prioritizzazione dei compiti man mano che si avvicina la loro scadenza. Questo perché l’obiettivo della cura del Product Backlog è assicurarsi che le funzionalità del Prodotto con il massimo valore commerciale, 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 subito nel prossimo Sprint.

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

L’aggiornamento obbligatorio del Backlog è uno dei compiti svolti durante la Sprint Review. Abbiamo descritto quel processo in dettaglio in questo articolo. Di solito, durante questo incontro, il Team Scrum discute non solo i compiti da completare nel prossimo Sprint. Specifica anche preliminarmente le User Stories e la loro implementazione nei successivi due o tre Sprints. Questo modo di fare consente al Team Scrum e alle sue attività di avere una visione più ampia della direzione a lungo termine. Permette di pensare ai compiti attualmente in corso dal punto di vista del loro sviluppo nei successivi Sprints.

Errori nella manutenzione del Product Backlog

Uno dei problemi più comuni riguardanti la cura del Product Backlog è consentire che si espanda in modo incontrollato. Questo perché, mentre si lavora sul Prodotto, varie funzionalità e compiti aggiuntivi proposti sia dagli Stakeholder che dai membri del Team Scrum appaiono spontaneamente. Pertanto, limitare la crescita dell’ambito del Product Backlog (scope creep) è uno dei compiti più importanti svolti dal Product Owner. Gli errori più comuni che i Product Owner commettono riguardano:

1. Deviare dall’Obiettivo del Prodotto – aggiungere troppe idee al Product Backlog oltre all’Obiettivo di Prodotto di base non è una buona pratica, poiché riduce notevolmente la sua leggibilità. È meglio raccogliere idee per funzionalità aggiuntive in un documento separato.
2. Duplicazione dei contenuti – inserire 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 prioritizzazione dovrebbe tenere conto dei prossimi diversi Sprints in modo che i compiti svolti in un dato Sprint siano collegati senza soluzione di continuità sia allo Sprint precedente che a quello immediatamente successivo.

Non puoi evitare errori di questo tipo. Tuttavia, la consapevolezza della loro occorrenza può rendere il Product Owner più cauto nell’aggiungere nuove User Stories al Product Backlog per trovare il giusto equilibrio. Questo perché è anche un errore dare troppo taglio al Backlog ed eliminare voci che contengono compiti simili che differiscono. Ad esempio, descrivere funzionalità del Prodotto simili che differiscono significativamente nell’applicazione.

Manutenzione del Backlog vs. metriche utilizzate in Scrum

Il Product Backlog contiene una descrizione del lavoro rimanente durante l’intero progetto. Tuttavia, solo un Backlog aggiornato e regolarmente curato può stimare accuratamente il rapporto tra la quantità di lavoro completato 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 del Team Scrum è la Velocità. Puoi misurarla confrontando il numero di voci del Product Backlog convertite in Incremento durante un singolo Sprint. Abbiamo descritto la Velocità in modo più dettagliato in questo articolo.

Riepilogo

Il Product Owner svolge la cura del Product Backlog. Quando il Product Backlog è ben mantenuto, il Team Scrum ha una visione chiara del lavoro che rimane. Può anche ottenere una prospettiva più ampia e orientata al futuro su come appare il percorso verso l’Obiettivo del Prodotto. Questo è il motivo per cui il Product Owner deve assicurarsi che le User Stories incluse nel Product Backlog siano ordinate in base alla priorità per il completamento. E anche che i compiti da completare nei prossimi Sprints siano descritti nel modo più dettagliato possibile.

Se ti piace il nostro contenuto, unisciti alla nostra comunità di api operose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.