Scrum and TFS cookbook - pt.3, go to the Sprint!

Dopo la creazione del Program Backlog e del Product Backlog, illustrate nel post precedente, siamo pronti a settare TFS/VisualStudioOnline per accompagnare il nostro Sprint: tuffiamoci nello Sprint Planning!

sprint plagging

Sprint Planning: let's start!

Cos’è lo Sprint Planning? Si tratta della cerimonia Scrum a cui è demandata lo start-up di un nuovo Sprint, sotto il cappello di uno “Sprint Goal” che definisce l’obiettivo d’insieme dell’iterazione stessa. Il goal guida la scelta delle User Story (PBI) che andranno a formare lo Sprint Backlog e che devono trovarsi al top dello stack che rappresenta il Product Backlog, cosa che le assegna un’alta priorità relativa.

Il numero di User Story da “inserire” nello Sprint hanno una relazione diretta con la Velocity raggiunta nello Sprint precedente dal Team, ottenuta sommando gli Story Point completati in funzione delle User Story completate. Nel caso in cui l’ultimo Sprint è stato interessato da eventi esterni che hanno inficiato il valore della Velocity, è possibile utilizzare una media storica come valore di riferimento.

Ma come stimiamo gli Story Point associati ad una User Story? Come sempre, esistono diverse tecniche, ma vi suggerisco il Planning Poker basato sulla sequenza di Fibonacci “corretta” che, inoltre, contribuisce alla discussione sulla singola User Story al fine di condividerne il significato ed il dominio.

planning-poker-fullfan

Le carte per il Planning Poker

L’attività di stima si svolge nel seguente modo:

ogni membro del Team ha un proprio deck di carte con sopra la sequenza di Fibonacci “corretta” (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinito, 0,5, ?). Lo Scrum Master legge ad alta voce la User Story e chiede ad ogni membro del Team di stimare la relativa complessità scegliendo una carta dal mazzo e posizionandola con il dorso verso l’alto su una scrivania di supporto. Sempre su indicazione dello SM, tutti i membri del Team girano contemporaneamente le carte: a questo punto chi ha indicato il valore più basso e chi ha indicato quello più alto dispongono di 3minuti per motivare la scelta. L’operazione si ripete finché il Team non raggiunge un’opinione comune sulla complessità della User Story. Nel caso in cui il valore scelto sia di 40, 100, infinito, è opportuno che la User Story venga messa da parte ed analizzata con dovizia per essere divisa in User Story più semplici.

Stimata la complessità della User Story, si passa alla definizione dei Task relativi che rappresentano l’unità minimale di lavoro stimata in ore. Il consiglio è quello di non effettuare una “stima verticale” (prima tutte le User Story e poi tutti i Task), ma seguire un approccio “orizzontale”: prendo una User Story dal Product Backlog, la stimo, definisco/stimo i relativi Task, passo alla successiva User Story. Questo per favorire una comprensione più di dettaglio della User Story corrente e di conseguenza del progetto, cosa che può essere sfruttata già nelle stime immediatamente successive.

La cosa migliore è quella di effettuare tutta la fase relativa allo Sprint Planning usando un approccio diretto, ovvero tramite flip-board, post-it, deck-card, ecc, e solo successivamente riportare il tutto su TFS/VisualStudioOnline. Questo per essere assolutamente in grado di adattare la cerimonia alle proprie esigenze e non essere vincolati ai constraints dello strumento.

Detto ciò, passiamo a TFS. Purtroppo l’ultima versione, compreso VisualStudioOnline, non dispone di “un’Area Sprint” o di uno “Sprint Work Item” per raccogliere lo “Sprint Goal” (congiuntamente ad alcuni altri elementi di Scrum), e, in attesa che vengano introdotti specifici elementi, possiamo associare lo Sprint Goal al nome dell’Iterazione, contando sul fatto che esso è tipicamente caratterizzato da una descrizione sintetica.

 tfs example 11

Sprint Goal

In alternativa è possibile, solo per TFS, creare un apposito Work Item o importare quello specifico esistente nella versione 2010.

tfs example 12

Sprint Work Item TFS 2010

Fatto ciò, l’attività da fare è quella di associare i Work Item (User Story) dello Sprint Backlog appena definito allo Sprint corretto definito in TFS, selezionando ed impostando l’Iterazione (Iteration) di assegnazione.

tfs example 13

Assegnazione Iterazione

Un’ulteriore utile aggiunta da fare è l’inserimento del “Peso” (Effort, ovvero Story Point) e del “Valore” (Business Value) per ogni User Story, valorizzando la sezione “Details” con quanto emerso durante il Planning Poker. Ciò sarà utile per gli strumenti di analisi.

tfs example 14

Effort e Priorità

Non ci resta ora che assegnare la Priorità, in accordo con lo Sprint Backlog ed il Product Backlog: questa azione è “implicita” nel senso che si ottiene spostando con il mouse i Work Item nell’ordine (alias priorità) desiderato. Completati tutti i settaggi, selezionando lo specifico Sprint, TFS vi presenterà un summary simile a quello seguente:

tfs example 15

Sprint summary

Una puntualizzazione: le uniche User Story ad essere state stimate sono quelle selezionate per lo Sprint in starting, mentre la stima di quelle rimanenti all’interno del Product Backlog è differita ai successivi Sprint Planning. Si tratta di una precisa scelta, legata alla teoria delle code (per approfondimenti, The Principles of Product Development Flow: Second Generation Lean Product Development - D. Reinertsen) in cui si dimostra l’inutilità di stimare completamente gli elementi di uno stack (alias Product Backlog), poiché la relativa conoscenza aumentare durante il progetto, alcuni di essi verranno eliminati ed altri introdotti.

Ciò rende praticamente inutile la funzionalità di “Forecast” (previsione) attivabile nella visualizzazione dei PBI perché richiede l’assegnazione dei pesi a tutti i Work Item, cosa in netta contraddizione con quanto appena detto.

tfs example 16

TFS Forecast

In sintesi: ignorate tale funzionalità, fa scena ma non serve a nulla.

Quello che invece bisogna settare è la Capacity (capacità) del Team sullo Sprint, selezionando chi lavorerà sul progetto, in quale sub-area e per quante ore al giorno. In tal modo si indicano le ore totali che il Team dedicherà allo Sprint, suddivise, se ha senso, per area.

tfs example 17

 Sprint "Capacity"

Questo dato risulta utile per avere costantemente una stima di capacità/carico di lavoro, che però diventa evidente solo con l’ultimo degli step che descriviamo oggi: l’inserimento dei Task relativi alle User Story incluse nello Sprint.

Selezioniamo “Board” e passiamo alla relativa visualizzazione:

tfs example 18

Sprint Board View

Clicchiamo sul segno “+” adiacente la User Story e creiamo un nuovo Task, compilando i relativi dettagli:

tfs example 19

Nuovo Task

Salviamo e, a questo punto, ci troveremo difronte a una Board contenente il nuovo Task con riportare le relative ore.

tfs example 20

Sprint Board

Ovviamente i Task da creare sono quelli definiti nello Sprint Planning.

La nostra finestra di stima della capacità del Team (alla destra dei Work Item nella visualizzazione Backlog dello Sprint) somiglierà alla figura seguente:

tfs example 21

Work

Si conclude così la fase di “pre-settaggio” dello Sprint sulla base di quanto emerso durante lo Sprint Planning. Da sottolineare l’uso del termine “pre-settaggio” scelto per evidenziare che l’ambiente di lavoro relativo ad un Sprint è in continua evoluzione e questa è solo una fotografia del suo stato nella fase iniziale.

Non ci resta che tuffarci nello Sprint vero e proprio, chiaramente nel prossimo post ;-)

Alcuni approfondimenti:

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme