mvp orizzontale  psm1 small  cdap  sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

  • Categoria: ALM
  • Scritto da Felice Pescatore
  • Visite: 1746

Product Backlog? Yes, but it can be more than one!

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:

product backlog office

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

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.

vso 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 M1

size m2

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 stesso 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

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

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:

  1. Program Backlog (Program Level): contiene tutto quanto necessario a rendere concreto l’Agile Release Train, in termini di iniziative e prodotti;
  2. Team Backlog (Team Level): è una segmentazione del relativo Program Backlog che contiene le attività di sviluppo associate allo specifico Agile Team.

program team backlog

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.