Sprint Planning orientato alla Velocity

Esistono due approcci fondamentali per pianificare uno Sprint:

1. Sprint Planning orientato alla Velocity (con riferimento al carico di lavoro medio di un team), e

2. Sprint Planning orientato al Commitment (con riferimento a ciò che un team ritiene di poter realizzare in uno Sprint).

Sprint Planning orientato alla Velocity

Qui si parla di Sprint Planning orientato alla Velocity. La quantità di lavoro pianificata per il prossimo Sprint dovrebbe corrispondere approssimativamente a quella degli Sprint precedenti. Questo presuppone naturalmente che la dimensione del team rimanga più o meno la stessa, che negli Sprint vengano svolte attività simili, che gli Sprint abbiano più o meno la stessa durata, ecc. Le deviazioni da questi presupposti possono fortunatamente essere individuate facilmente. Se, ad esempio, uno Sprint dura solo nove giorni invece di dieci a causa di un giorno festivo, il team lo sa naturalmente in anticipo.

I singoli passaggi dello Sprint Planning orientato alla Velocity:

• Determinare quale fosse la Velocity media del team negli Sprint precedenti.

• In base a questa Velocity, selezionare il numero corrispondente di Product Backlog Item.

• Identificare i singoli task delle User Story e valutare se potrebbe essere la giusta quantità di lavoro.

• Stimare se questi task richiedono la stessa quantità di lavoro di quelli degli Sprint precedenti.

Esaminiamo questi passaggi più in dettaglio.

Passaggio 1: determinare la Velocity media di un team

Il primo passaggio dello Sprint Planning orientato alla Velocity è determinare la Velocity media di un team. Alcuni team agili si orientano solo alla Velocity dell'ultimo Sprint. Molti team ritengono che sia il miglior indicatore di ciò che può essere realizzato nel prossimo Sprint. Questo naturalmente non è sbagliato. Tuttavia può essere utile guardare un po' più indietro (se i dati sono disponibili).

Per farlo si esamina la Velocity degli ultimi tre-otto Sprint. L'esperienza mostra che in questo modo si possono prevedere abbastanza bene gli Sprint futuri. Naturalmente non bisogna esagerare e calcolare la media degli ultimi dieci anni. Questo non direbbe nulla sulla Velocity attuale di un team. Tuttavia, se i dati degli Sprint precedenti sono disponibili, è meglio non guardare solo all'ultimo Sprint.

Passaggio 2: selezionare i Product Backlog Item

In base alla Velocity media appena determinata, i membri del team possono selezionare gli item per il prossimo Sprint. Insieme dovrebbero corrispondere – almeno approssimativamente – alla Velocity media.
A questo punto lo Sprint Planning orientato alla Velocity è in linea di principio completato e può essere svolto in pochi secondi – una volta che il team ha selezionato i Product Backlog Item in base alla Velocity media, ha finito.

Passaggio 3: identificare i task (opzionale)

Spesso questo breve tempo per uno Sprint Planning non è realmente sufficiente. Pertanto i team possono aggiungere un terzo passaggio alla pianificazione, in cui vengono identificati i task da eseguire.
I membri del team discutono ogni singolo Product Backlog Item selezionato per lo Sprint. Cercano di determinare quali passaggi di lavoro sono necessari per completare gli item. Naturalmente non si può pensare a tutto, ma bisogna cercare di includere il più possibile.

Dopo, il team valuta se gli item selezionati e i relativi task riempiranno lo Sprint. Di conseguenza possono essere aggiunti o rimossi alcuni item dallo Sprint.

Alcuni team terminano qui il loro Sprint Planning, altri eseguono ancora un ultimo passaggio:

Passaggio 4: stimare i task (opzionale)

Alcuni team alla fine stimeranno quante ore probabilmente saranno necessarie per i task selezionati. Da questo possono capire se hanno pianificato la giusta quantità di lavoro.

Questo testo proviene dal blog di Mike Cohn ed è stato tradotto.