ALM, torniamo sulla priorizzazione dei Work Item

Nel precedente post “ALM, priorizzare le User Story per Valore… ma non solo”, abbiamo definito l’Iteration Value di una User Story, ovvero una stima più profonda (deep estimation) del principale Work Item a livello Team (rif. SAFe, Leffingwell, in DAD siamo nella fase di Construction).

In breve, con uno scope più esteso, non legato esclusivamente alle User Story, abbiamo:

Iteration Value = Business Value + Risk Value + Team Engagement Value.

Quello che non abbiamo completamente esplicitato è l’Estimation Timing, ovvero in quale momento avviene la stima dell’Iteration Value. Ebbene, possiamo considerare l’Iteration Value come la somma di due stime che avvengono in momenti differenti:

Iteration Value = [Work Item Value]T0 + [Team Engagement]Ti

riconoscendo due metriche diverse:

  • Il Work Item Value (Business + Risk Value) è la stima che viene effettuata all’atto della priorizzazione del Team Backlog. Tale stima viene tipicamente effettuata con discreta profondità dal Product Owner (e se presente dal Product Manager), con il supporto del Team, ad inizio del nuovo ciclo di iterazioni. E’ utile chiarire che con “Team Backlog” si intende l’insieme dei Work Item relativi alle feauture presenti nel Release Backlog (derivato a sua volta dal Program Backlog) affidati al Team specifico, nel caso in cui più Team sono coinvolti nello sviluppo. Se siamo in presenza di un unico Team, è possibile ricondurre il tutto all’uguaglianza: Release Backlog = Team Backlog;
  • Team Engagement Value è la stima che viene associata al Work Item al momento in cui viene creato il Backlog di Iterazione.

In sostanza, i Work Item possono essere rivalorizzati just-in-time all’avvio di una nuova iterazione, seguendo più velocemente l’evoluzione del team.

Facciamo un rapido esempio: il Product Owner (e il Product Manager se presente), con il supporto del Team, a T0 definisce il Work Item Value per ogni elemento presente nel Team Backlog. Dopo 4 iterazioni (T4), lo stato del Team Backlog è il seguente:

#Work Item

Business Value

Risk Value

Work Item Value

3

1

8

9

4

6

2

8

1

4

3

7

….

….

….

….

Team Backlog a T4

Ipotizziamo che la nostra Velocity sia di 20 story point, cosa che ci consente di realizzare, nella nuova iterazione (5), la WI3 e WI4.

Ma siamo sicuri che la priorità associata inizialmente ai Work Item del Team Backlog non vada rivista per tener conto della storia delle iterazioni completate? La risposta è senza ombra di dubbio no! Anzi, è sicuramente l’opposto.

A questo punto qualcuno potrebbe chiedersi: “perché non ripriorizziamo l’intero Team Backlog?” L’osservazione è corretta, ma se l’approccio può essere proficuo per un Team Backlog non particolarmente ampio (20-25 Work Item), cosa accade se abbiamo un Team Backlog di 100 Work Item? (ok, non è il massimo, come dimostreremo con la Little’s Law, ma rende l’idea J). Inoltre, se il Team Backlog è un sottoinsieme del più ampio Release Backlog, le modifiche che vado ad apportare come influenzano, direttamente o indirettamente, quest’ultimo, più vicino agli obiettivi di business?

Ebbene, proprio per coniugare le diverse esigenze ci viene in soccorso il Team Engagement Value:

#Work Item

Work Item Value

Team E. Value

Iteration Value

3

9

2

11

4

8

4

12

Team Backlog rifattorizzato

In questo caso, l’Iteration Value del WI4 è superiore a quello del WI3, sovvertendo, di fatto, l’ordinamento in funzione alla storia del Team. In linea di massima è possibile anche decidere di ignorare del tutto il Team Engagement Value, considerando il relativo valore pari a 0, e utilizzando un Iteration Value = Work Item Value.

Per tener traccia di tutte queste informazioni, sfruttando TFS on premises (purtroppo non Visual Studio Online che ancora non permette le modifiche ai process template), possiamo modificare la definizione del Work Item, aggiungendo i campi relativi, in modo più strutturato rispetto a quanto presentato sempre nel post citato all’inizio.

Per fare le modifiche necessarie, è possibile ricorrere ai Microsoft Visual Studio Team Foundation Server 2013 Power Tools e operare da Visual Studio 2013 connettendosi direttamente a TFS. In alternativa si può scegliere di editare manualmente il file xml del Process Template in uso.

Il risultato dovrebbe essere simile al seguente:

iteration value2

La cosa importante è che, in questo modo, si riduce l’impatto della stima UP-Front (Work Item Value) che, per quanto minima, comunque non è in grado di predire l’evoluzione del Team, soprattutto in contesti nuovi.

Nei prossimi post torneremo su questi argomenti, introducendo il concetto di Weighted Shorted Job First, associato alla priorizzazione delle feature, elemento fondante del Program e Release Backlog (SAFe, Leffingwell – in DAD siamo nella fase di Inception), e parleremo della già citata Little’s Law.

Comments are closed.