Nello sviluppo agile, un product backlog (spesso indicato semplicemente come backlog), di proprietà del Product Owner, è un elenco di tutte le cose (nuove funzionalità, correzioni di bug, miglioramenti, modifiche alle funzionalità esistenti e altre iniziative di prodotto) a cui i team di prodotto devono fornire, in ordine di priorità, affinché un prodotto prenda vita strategicamente.
In sostanza, il backlog è un'unica fonte di verità per tutto ciò su cui il team di prodotto deve lavorare. Non viene creato nulla a meno che non si trovi nel backlog del prodotto. D'altra parte, elencare un qualcosa nel backlog non garantisce la consegna. In questo senso, il backlog è un ampio elenco di cose da fare di tutte le attività relative al prodotto che il team ha acquisito ma non si è ancora impegnato a realizzare.
Il product backlog è un documento vivo. Man mano che i team di prodotto acquisiscono migliori dettagli sul problema e del lavoro necessario per fornire la giusta soluzione, gli elementi del backlog esistenti possono essere riordinati o rimossi o addirittura possono essere aggiunti nuovi elementi. Non tutto può essere una priorità assoluta durante la creazione di un prodotto. Un backlog ben curato mantiene agili i team di prodotto sfidando l'importanza delle funzionalità e mantenendo sincronizzate le priorità di tutti.
Mentre l'intero team lavora e contribuisce al product backlog, il Product Owner è responsabile della manutenzione del backlog.
Nella metodologia Scrum, il product owner Scrum è ritenuto responsabile del mantenimento di un backlog sano, mentre lo Scrum Master, il team Scrum e altri stakeholder contribuiscono aggiungendo nuove voci e completando attività nel backlog.
Possono esistere diversi proprietari di backlog quando i team utilizzano più backlog. Ad esempio, il product backlog principale potrebbe essere gestito dal product owner, mentre il team tecnico potrebbe essere responsabile dello sprint product backlog .
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
- Compiti tecnici (esempio: setup di ambienti)
- Acquisizione di competenze o indagini (Spike)
- Nuove idee per le funzionalità
- Bug di tutti i livelli e gravità
- Correzioni di bug
- Miglioramenti delle funzionalità
- Richieste di funzionalità da clienti e stakeholder
- Modifiche al design
- Problemi di UX
- Cambiamenti infrastrutturali
Ogni attività ha una stima dell’effort e in Scrum è una pratica comune effettuare le stime in Story Point (abbreviato SP).
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.
A seconda dell'approccio del tuo team alla gestione dei prodotti e della metodologia agile che utilizzi, potresti scegliere tattiche e processi diversi per creare e gestire il tuo backlog dei prodotti.
Ci sono alcune regole universali che manterrebbe il tuo team sincronizzato e ti salverebbe dagli ostacoli di un arretrato travolgente:
- Assicurati che ogni membro del team comprenda e adotti il tuo processo per la gestione del backlog..
- Imposta i criteri su elementi che appartengono al backlog. È essenziale che tutti contribuiscono, ma devi evitare di espandere il backlog con voci che non aggiungono valore al prodotto.
- Il proprietario del backlog dovrebbe rivedere tutte le voci per assicurarsi che la definizione delle priorità sia corretta e che sia stato incorporato il feedback più recente del team.
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:
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.
Un altro strumento utile a organizzare il backlog in maniera “visuale” è 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à.
Il product backlog è un elenco compilato di tutti gli articoli che devono essere consegnati per completare l'intero progetto o prodotto. Lo sprint backlog, d'altra parte, è un sottoinsieme del main product backlog. Gli elementi nello sprint backlog vengono selezionati dal product backlog principale, ma lo sprint backlog contiene solo le attività che possono essere completate durante lo sprint. Lo sprint backlog aiuta a ridurre il carico di lavoro e ad aumentare l'efficacia del team concentrandosi solo sulle iniziative che possono essere completate durante lo sprint.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
