---

Che cos'è lo Scrum Product Backlog? Potrebbe sorprenderti!

Il Product Backlog (Scrum Backlog), o Scrum Product Backlog, è l'elemento centrale per gestire tutti i requisiti noti di un prodotto Scrum.

Comprende il lavoro emergente e ordinato necessario a migliorare il prodotto e raggiungerne gli obiettivi. Tra i requisiti figurano quelli funzionali e non funzionali e altre funzionalità relative all'esperienza utente e alla progettazione dell'interfaccia.

Contiene richieste di funzionalità e relative user story generali. Può includere prerequisiti o requisiti complementari, come ambienti di test e sviluppo. Vi trovano posto anche storie per risolvere bug noti, ridurre debito tecnico o migliorare funzionalità.

Ogni prodotto ha un Product Backlog condiviso da tutti i team che vi lavorano. Lo Scrum Product Owner ne cura creazione, manutenzione e affinamento. Non risponde, e non dovrebbe rispondere, alla domanda su come sviluppare e consegnare i requisiti.

Questo spetta al team, che decide e documenta le attività necessarie negli Sprint Backlog. Product Backlog e Sprint Backlog sono entità fisicamente separate, anche se gli elementi del primo guidano i contenuti del secondo.

Il titolare dello Product Backlog Scrum è lo Scrum Product Owner. Scrum Master, team e altri stakeholder contribuiscono a costruire un elenco più ampio di user story per il successo del prodotto.

Lavorare con il backlog non vieta altri artefatti, come riepiloghi dei ruoli utente, descrizioni di flusso, linee guida dell'interfaccia, storyboard o prototipi. Non lo sostituiscono: ne completano e dettagliano i contenuti.

Il Product Backlog è un documento vivo. Come il software migliora in modo incrementale, anche il Product Backlog cresce nel tempo. Scrum non richiede un processo separato di gestione del cambiamento. Il Product Owner crea le prime versioni sulla base della migliore comprensione iniziale del prodotto.

Mentre osserva l'evoluzione del prodotto da uno Sprint all'altro e aumenta la conoscenza delle esigenze dei clienti, aggiunge, elimina e affina i requisiti.

Lo Scrum Product Owner assegna priorità ai requisiti. Più un elemento è prioritario, più dovrebbe essere dettagliato, così che il team possa comprenderlo facilmente e creare le attività per realizzarlo.

I Developer dimensionano inoltre gli elementi secondo necessità; gli story point sono una tecnica facoltativa. Le stime delle storie prioritarie vanno affinate per prepararle allo Sprint Planning.

Ogni Scrum Product Backlog ha attributi specifici che lo distinguono da una semplice lista di cose da fare:

• Una user story aggiunge sempre valore aziendale o tecnico a cliente, titolare dell'attività e utenti finali,
• Tutte le storie sono ordinate dalla priorità più alta alla più bassa,
• I dettagli di una storia dipendono dalla sua posizione nel backlog,
• Le storie vengono dimensionate secondo necessità con una tecnica adatta,
• Il backlog è un documento vivo,
• Descrive il lavoro sul prodotto; il piano esecutivo dettagliato dei Developer appartiene allo Sprint Backlog.

Le user story aggiungono valore a cliente, azienda e sistemi

Ogni user story deve offrire valore al cliente. Quelle senza valore per il cliente sono puro spreco di risorse e vanno eliminate. Il Product Backlog può includere storie per:

• Specificare requisiti funzionali e non funzionali,
• Riassumere la suddivisione generale del lavoro per lanciare il prodotto,
• Predisporre ambienti non di produzione per sviluppo e dimostrazione,
• Correggere difetti.

Esempio di Scrum Product Backlog

Alcune attività non aggiungono valore diretto alla funzionalità o ai clienti aziendali. Devono comunque offrire valore aumentando la qualità, riducendo il debito tecnico e migliorando la manutenibilità a lungo termine.

Il Product Backlog è un documento vivo

Cambia ed evolve durante tutto il progetto. Si aggiungono storie, altre possono essere modificate, dettagliate o eliminate. I requisiti Scrum non sono più congelati all'inizio come in Waterfall.

L'insieme finale viene invece sviluppato iterativamente insieme agli incrementi software emergenti.

È diverso dall'ingegneria tradizionale dei requisiti. Consente però di massimizzare il valore per il cliente e ridurre gli sprechi.

Diversi livelli di dettaglio

I requisiti possono avere diversi livelli di profondità e granularità. Soltanto quelli da implementare nei prossimi Sprint vanno definiti più dettagliatamente. Le altre storie devono restare generali ed essere elaborate «just-in-time», prima che il team debba saperne di più.

Non ha senso investire tempo e risorse per specificarli in anticipo: potrebbero cambiare o scomparire prima dell'implementazione. La gestione «just-in-time» dei requisiti è uno dei migliori vantaggi di Scrum per affrontare ciò che nei progetti «non sappiamo di non sapere».

Niente attività di dettaglio nel Product Backlog

Il Product Backlog descrive normalmente il lavoro sul prodotto, non la suddivisione dettagliata delle attività. Il Product Owner definisce i requisiti con clienti e stakeholder prima di portarli all'affinamento o allo Sprint Planning. I Developer sono responsabili della suddivisione dettagliata e dell'organizzazione del lavoro.

Lo Scrum Product Backlog è ordinato per priorità

Tutte le user story sono ordinate dalla priorità massima alla minima. Il Product Owner assegna le priorità con il sostegno del team. I fattori più comuni sono valore aggiunto per l'attività del cliente, costi, rischi e dipendenze. Il Product Owner può così decidere che cosa costruire e consegnare successivamente.

Stimare le dimensioni degli elementi del Product Backlog

I Developer possono dimensionare con tecniche concordate, come story point in stile Fibonacci o dimensioni relative S/M/L/XL/XXL. Scrum non impone una scala né stime per ogni elemento lontano. Approfondiremo in seguito. Le stime influiscono su capacità degli Sprint, contenuto dello Sprint Backlog e piani di rilascio.

Lavorare con il backlog

Il Product Backlog richiede cura e attenzione regolari, perché è il riferimento autorevole per comprendere di che cosa tratta il prodotto software.

All'inizio contiene molte storie generali che possono essere più o meno rilevanti per il successo. Da uno Sprint all'altro, Product Owner e team imparano di più sul progetto.

I contenuti riflettono quindi sempre meglio il prodotto e ciò che il team ha appreso.

Dopo la preparazione iniziale, serve manutenzione continua, che comprende:

• Descrivere e aggiungere nuovi requisiti scoperti; modificare o rimuovere quelli esistenti dove appropriato,
• Ordinare per priorità il Product Backlog, spostando in alto le storie più importanti,
• Preparare le storie prioritarie per lo Sprint Planning, generalmente durante l'affinamento,
• Stimare o ristimare le storie, generalmente durante l'affinamento.

Il Product Owner deve assicurare che il backlog sia sempre in buono stato, ma mantenerlo è un processo collaborativo. Va riservata una capacità ragionevole dei membri all'affinamento continuo, oltre al tempo necessario agli eventi Scrum.

La manutenzione collaborativa chiarisce inoltre i requisiti e crea adesione al prodotto emergente nei membri del team.