Per completare il nostro Sprint ci attendono due appuntamenti (cerimonie) fondamentali: lo Sprint Review e lo Sprint Retrospective.
Sprint Review and Sprint Retrospective meeting
Lo Sprint Review è dedicato alla presentazione del lavoro svolto, o meglio, dell’attuale stato del prodotto, comprendente tutto quanto sviluppato finora, integrato e testato. Ad esso partecipano praticamente tutti: gli stakeholder (interni ed esterni), lo Scrum Team al completo, uditori, ecc… Scrum prevede di effettuare lo Sprint Review alla fine di ogni sprint ma, in realtà, è sempre più frequente l’utilizzo del concetto di Minimum Viable Product (mvp), ovvero l’insieme minimo di funzionalità che rappresentano un incremento significativo dal punto di vista del cliente. Se applicato (cosa di frequente soprattutto quando lo sviluppo del prodotto coinvolge più Team) la cosa si traduce nell’avere uno Sprint Review interno minimale e uno Sprint Review più consistente ogni N-Sprint.
Durante lo Sprint Review vengono evidenziati eventuali problemi di sviluppo che si sono verificati e come evitarli in futuro. Tra essi, uno dei più frequenti, è il comportamento da adottare rispetto a User Story completate solo parzialmente.
Personalmente, suggerisco al Team di applicare due semplici regole:
- Una User Story non completata (o meglio, che non ha raggiunto lo stato di “Done”) non contribuisce al calcolo della Velocity;
- L’intera User Story, compresi i Task completati e non, vengono traslati nel nuovo Sprint.
Un approccio alternativo al punto 2 è quello di “splittare” la User Story in UserStoryA e UserStoryB, la prima comprende i Task completati e la seconda quelli non completati. In questo modo la UserStoryA contribuisce anche alla Velocity dello Sprint attuale, mentre il resto va nello Sprint successivo. Questo approccio ha lo svantaggio di dover ri-estimare anche la complessità delle due nuove User Story e, in generale, non è del tutto compliance con l’essenza di Scrum.
Il primo supporto a questa fase da parte di TFS/VisualStudioOnline è chiaramente legato alla Continuous Integration (Pt.4, Sprint by Sprint) che consente di ottenere una soluzione completa e testata delle nuove funzionalità realizzate in modo automatizzato. Lo strumento ALM di Microsoft ci viene incontro anche nell’attività di riallocare una User Story con tutti i relativi task in modo semplice e veloce: basta selezionare la User Story specifica e cambiare la sua “assegnazione”.
User Story Iteration Assignment
Se si desidera spostare solo i task non competi, la procedura è un po’ più complessa: TFS/VisualStudioOnline, in modo automatizzato, permette lo “share” di una User Story tra più Sprint (Iterazioni), quindi non è necessario effettuare la ri-stima per due User Story differenti. Vediamo come fare: prima di tutto bisogna creare una query che selezioni i task “undone”.
Done / unDone Task query
Dopodiché selezionate il risultato ottenuto (sia la User Story che i Task), cliccate con il tasto destro sulla selezione e scegliete “Move to Iteration”.
Move to Iteration
Una volta confermato il tutto avrete la User Story presente sia nell’iterazione corrente, con i relativi Task in Done state, e nell’iterazione successiva (o quella che avete indicato) con i Task non-in-Done-State.
Shared User Story: Sprint Attuale
Shared User Story split: Sprint Successivo
Essendo la User Story in “share”, risulterà ancora aperta alla fine dello Sprint corrente e, automaticamente, non correrà al calcolo della Velocity.
A valle delle operazioni di “aggiustamento”, lo Sprint Review si conclude con una serie di domande molto simili a quelle poste durate il Daily Scrum, di preparazione al prossimo Sprint Planning (Pt.3, go to the Sprint!):
- What did you like the most ?
- What did you not like?
- What would you like to improve?
Una volta terminata lo Sprint Review, lo Scrum Team (e solo esso) si riunisce per 2-3 ore per effettuare la Scrum Retrospective. Questo meeting è caratterizzato da una serie di Activity che consento di ispezionare l’applicazione di Scrum stesso e il comportamento del Team come tale, al fine di migliorare l’aspetto metodologico del lavoro. Spesso, come Activity, si utilizzano dei Retrospective Game come lo Starfish che consentono di raccogliere in modo chiaro e coinvolgente i vari aspetti che caratterizzano il Team.
Starfish game
Da questo punto di vista, TFS/VisualStudioOnline non offre un grande supporto avendo, come detto, nella versione 2013 eliminato lo “Sprint Work Item”. L’opzione potrebbe essere quella di creare, a questo punto, un Work Item generico nella cui descrizione si inseriscono gli obiettivi (agenda) della retrospettiva e si allegano le foto dei vari artefatti realizzati.
Retrospective Work Item
Si tratta di un Work Item utile per aver traccia di quanto discusso nella retrospettiva, legandolo in modo diretto allo Sprint.
Siamo giunti alla fine del nostro “cookbook”, un viaggio lungo 5 post in cui abbiamo visto alcune soluzioni pratiche che consentono a TFS/VisualStudioOnline di supportare in modo diretto l’utilizzo di Scrum all’interno della propria organizzazione.
Sperando che il tutto vi abbia incuriosito e possa servirvi come start-point per le vostre esigenze, chiudo ricordandovi che sia TFS/VisualStudioOnline che Scrum vanno sempre calati nello specifico contesto di esercizio e che solo un loro utilizzo serio e disciplinato porta ad vero valore per le proprie attività.
