Il Product Backlog è la proiezione, ordinata e pesata, di quello che è il nostro Prodotto, o almeno di quanto, allo stato attuale, si conosce di esso.
In linea generale abbiamo un’associazione diretta tra Product Backlog, Prodotto e Agile Team, ovvero: per 1 Prodotto esiste 1 Product Backlog ed 1 Agile Team che ne prende in carico le attività. Si tratta, chiaramente, di uno scenario minimale che si complica notevolmente già solo ponendosi una semplice domanda: “Che cos’è per noi un Prodotto?”.
Facciamo un esempio molto semplice, tratto dall’ottimo libro Essential Scrum di Kenneth S. Rubin: se consideriamo Microsoft Office, possiamo etichettare come Prodotto l’intera Suite o una delle sue applicazione specifiche, per esempio Word:
Cos’è per noi il “Prodotto”?
Ebbene, la scelta di dove posizionarsi raramente è ben delineata dipendendo da una serie di elementi che afferiscono principalmente al Program Level (leggasi SAFe), in accordo con gli obiettivi strategici.
Ora, tralasciando la governance di questo aspetto, proviamo a vedere alcune strategie utili per gestire il nostro Product Backlog in base alla nostra definizione di “Prodotto” e a quanti Team sono associati ad esso. Chiaramente andiamo a scoprire anche come sfruttare adeguatamente VisualStudioOnline/TFS per accompagnare tali strategie.
Prima di procedere, utilizzando una stima della complessità dei progetti in linea con le T-Shirt Size, vediamo i possibili casi principali (sicuramente non esaustivi):
|
Size |
Product Type |
Team |
|
S |
Bassa Complessità |
Uno/Generalista |
|
M |
Media Complessità |
N/Generalisti |
|
L |
Alta Complessità |
N/Generalisti e Specialisti |
Size Case
Size S. In questo scenario possiamo adottare l’approccio più classico, in cui si ha un unico Product Backlog a cui afferisce un unico Agile Team. Come di consueto, il Product Backlog conterrà i Work Item più rilevanti e più dettagliati al Top.
Size S
Guardando a VSO/TFS non è necessario fare particolari settaggi, essendo possibile utilizzare il Product Backlog e l’associazione dell’Agile Team al Team Project esattamente come viene creato scegliendo lo Scrum Process Template.
Scrum Process Template Items Tree
L’unica accortezza è quella di considerare le Feature (o Work Item a “grana grossa” se preferite) parte del Portfolio Backlog e le User Story/Bug/ecc… come elementi del (Product) Backlog legati alle Feature.
Size M. Questo scenario può essere suddiviso in due sub-scenari specifici:
- M1: il nostro Prodotto è unico ed è associato a più Agile Team che lavorano sulle relative Feature;
- M2: il nostro Prodotto è in realtà composto da più Prodotti specifici e ognuno di essi è associato uno specifico Product Backlog affidato ad un Agile Team;
Size M1
Size M2
Per quanto riguarda le relative configurazioni di VisualStudioOnline/TFS, sia per Size M1 che Size M2, vi rimando direttamente agli ottimi post di Gian Maria Ricci (Gestire Team Multipli con uno sesso backlog in un Team Project e Configuration di un Team Project per più team con backlog multipli) in cui viene spiegato passo-passo come sfruttare le “Aree” di VSO/TFS per raggiungere la configurazione desiderata.
VSO Area Configuration
Size L. E’ lo scenario più difficile, in cui abbiamo una serie di sotto Prodotti, ognuno dei quali può essere affidato a più di un Agile Team, sia generalista che specialista.
Size L
Anche per quest’ultimo scenario, valgono i post di Gian Maria, che opportunamente combinati portano al risultato desiderato.
Prima di chiudere un breve cenno sullo Scaling, relativamente a SAFe. Il framework di Leffingwell, non contempla nessun Product Backlog, dal punto di vista letterale, bensì, ragionando in termini di Value Stream e ART, individua due Backlog differenti, posizionati in due livelli distinti:
- Program Backlog (Program Level): contiene tutto quanto necessario a rendere concreto l’Agile Release Train, in termini di iniziative e prodotti;
- Team Backlog (Team Level): è una segmentazione del relativo Program Backlog che contiene le attività di sviluppo associate allo specifico Agile Team.
SAFe Program e Team Backlog
Quanto proposto da SAFe rientra nel caso Size L, poiché il Program Backlog è un’entità complessa che può sicuramente essere composta da più Prodotti.