Il Product Backlog in Scrum

Il Product Backlog è un artefatto ufficiale di Scrum che consiste in un elenco di attività (Product Backlog Item) ordinato per priorità. Il Product Backlog viene costantemente rivisto e riordinato dal Product Owner in base alle necessità degli utenti o del cliente, le aspettative degli stakeholder, nuove idee, o in seguito alle esigenze di mercato - ma anche in base a suggerimenti da parte del team.

Definizione di backlog

Il Product Backlog è di proprietà del Product Owner, è un documento in continua evoluzione e ha la finalità di raggiungere un obiettivo a lungo termine per il prodotto: il Product Goal. Nonostante lo sviluppo agile si basi su piccole iterazioni, la stesura di una Roadmap è uno strumento ampiamente utilizzato per dare visibilità su tutte le attività che si prevede contribuiranno al raggiungimento di questo obiettivo.

In fase di pianificazione, quindi durante lo Sprint Planning, i Developer prendono in esame un sottoinsieme del Product Backlog. In particolare tutti i Product Backlog Item con priorità più alta, e che quindi si trovano in cima all'elenco.

In alcune organizzazioni si fa anche uso del Release Backlog, che consiste in un elenco di Product Backlog Item che devono far parte di una determinata release. Dato che in Scrum e Agile lo scope non è mai fisso e definito a monte, il Release Backlog non fa parte degli artefatti ufficiali di Scrum e non lo approfondirò ulteriormente. Il Product Backlog è quindi l'unica sorgente per il lavoro dei Developer del team.

Com'è fatto il Product Backlog in Scrum

All'interno di un Product Backlog trovano spazio i Product Backlog Item, che tradotto letteralmente significa "elementi del Product Backlog". Questi elementi descrivono diversi tipi di attività o iniziative, come per esempio:

• Nuove feature e Change Request
• Bug
• Compiti tecnici (esempio: setup di ambienti)
• Acquisizione di competenze o indagini (Spike)

Ogni attività ha una stima dell'effort e in Scrum è una pratica comune effettuare le stime in Story Point (abbreviato SP), ne parleremo presto.

Per quanto riguarda i bug, dovrebbero anch'essi far parte del Product Backlog, nonostante ci siano pareri contrastanti in merito. Scrum non suggerisce di per sé alcuna pratica, ma dal momento che ciascun "defect" origina una modifica al prodotto originario, ha perfettamente senso includerli come attività nel Product Backlog.

Anche i compiti più tecnici, le indagini e l'acquisizione di nuove competenze, trovano posto all'interno del backlog in quanto vanno pianificati insieme al team. Se queste attività non si pianificano è molto facile dimenticarsene o non trovare lo spazio adeguato per l'esecuzione.

Il mio consiglio è comunque di limitare al minimo i task per le indagini, chiamati anche Spike, per non cadere nella trappola Waterfall: ovvero voler analizzare attentamente ogni dettaglio prima di iniziare a scrivere codice. Le Spike non devono mai essere utilizzate come uno strumento di analisi dettagliata o di preparazione per lo Sprint successivo.

L'obiettivo, in Scrum e nelle metodologie agili, è infatti creare valore aggiunto attraverso il rilascio di software funzionante in maniera incrementale e iterativa, e di imparare dai risultati conseguiti.

Esempio di Product Backlog

Le nuove feature e change request vengono convenzionalmente scritte sotto forma di user story, leggi il mio articolo su user story e acceptance criteria per capire come sono strutturate.

By agileway.it - Creative Commons. Clicca per ingrandire.

Ti riporto, nell'immagine qui sopra, un esempio di Product Backlog. Puoi inserire in tabella altre informazioni, come il valore di business e l'indice di rischio, oppure puoi decidere di inserirle su una pagina wiki o su uno strumento esterno di monitoraggio.

Come ordinare il Product Backlog

Come già accennato in apertura di articolo, il backlog è ordinato per priorità. In cima all'elenco ci sono attività con valore di business più alto o che necessitano, per altri motivi, di essere svolte per prime. In fondo al backlog trovano posto quelle attività che non sono di vitale importanza o che non hanno abbastanza elementi per poter essere prese in considerazione. Molte delle user story che si trovano al fondo di un tipico Product Backlog possono anche non essere mai implementate e di conseguenza essere rimosse dal Product Owner in fase di revisione.

Un buon metodo per tenere il Product Backlog ordinato è creare o etichettare le attività per aree tematiche o gruppi di funzionalità. In Scrum viene solitamente utilizzata la parola inglese theme per indicare questi raggruppamenti. In italiano potremmo tradurre con "temi".

All'interno di ciascun theme possono essere raggruppate diverse attività affini che vanno a comporre un'area funzionale dell'applicazione o del prodotto. Normalmente ciascun raggruppamento contiene un minimo di due attività. Un esempio, oltre all'immagine qui sopra, può essere il seguente:

Theme****AttivitàArea utenti- Login
- My Account
- Downloads
- Logout

Un theme può contenere attività con priorità diverse, per esempio il Product Owner potrebbe decidere di lanciare l'Area Utenti anche senza la parte di Downloads. La finalità dei theme è di rendere immediatamente accessibili e riconoscibili le informazioni; è una buona idea usare un colore diverso per ciascun raggruppamento.

Story Mapping

Un altro strumento utile a organizzare il backlog in maniera "visuale" è Story Mapping, argomento che ho affrontato in questo articolo. Story Mapping dà una visione più accessibile del nostro Product Backlog ed è utile per comunicare i casi d'uso, l'interazione dell'utente finale con il nostro prodotto (user journey) e le priorità.

Immagine di copertina rilasciata via Creative Commons da Nikki Buitendijk su Flickr.