Il Product Backlog in Scrum

Il Product Backlog in Scrum è un elenco di attività e di feature 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, ed è redatto in seguito all’identificazione di una vision e alla stesura di una Roadmap. Nonostante lo sviluppo agile si basi su piccole iterazioni, la Roadmap è uno strumento fondamentale per la definizione di obiettivi di medio e lungo termine, e ti consiglio vivamente di farne uso!

Quando si estrae o si prende in esame un sottoinsieme del backlog, quello con priorità più alte al fine di pianificare un rilascio, spesso si usa il termine Release Backlog. Non preoccuparti se in questo momento ti sfugge la differenza tra Roadmap, Product Backlog e Release Backlog. Torneremo su questi concetti in approfondimenti e articoli successivi.

Com’è fatto il Product Backlog in Scrum

All’interno di un Product Backlog puoi trovare diversi tipi di attività come per esempio:

  • Nuove feature e Change Request
  • Bug
  • Compiti tecnici (esempio: setup ambienti)
  • Indagini e acquisizione competenze

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, ti consiglio di utilizzare strumenti per il monitoraggio come Trac, Redmine o Bugzilla (questi tool sono detti bug tracker). Vedremo insieme in uno dei prossimi articoli com’è possibile gestire i bug efficacemente dal punto di vista del processo, in modo da mantenere il Product Backlog il più pulito possibile.

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 questo tipo di task all’interno di un’iterazione, dal momento che l’obiettivo, in Scrum e nelle metodologie agili, è creare valore aggiunto attraverso il rilascio di funzionalità in maniera incrementale.

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

product backlog

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, 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 è raggruppare le attività per aree tematiche o gruppi di funzionalità – viene utilizzata la parola inglese theme per indicare questi raggruppamenti.

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:

ThemeAttività
Area utenti– Login
– My Account
– Downloads
– Logout

Un area tematica 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.

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