Sprint Planning orientato al Commitment

Ci sono due possibilità 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 crede di poter realizzare in uno Sprint)

Lo Sprint Planning orientato alla Velocity l'ho già illustrato, quindi qui ci concentriamo sullo Sprint Planning orientato al Commitment:

I meeting di Sprint Planning orientati al Commitment coinvolgono il Product Owner, lo Scrum Master e l'intero team di sviluppo. Il Product Owner fornisce una panoramica dei Product Backlog Item con la priorità più alta e li spiega al team.

Selezionare un item

Successivamente, i membri del team scelgono un item per il prossimo Sprint. Nella maggior parte dei casi, questo corrisponde all'item a cui anche il Product Owner ha attribuito la priorità più alta. Può però capitare che l'item del Product Owner contenga ancora troppi punti aperti.

Idealmente, il team dovrebbe comunque essere in grado di inserire questo item nello Sprint e chiarire le questioni aperte abbastanza presto da poter completare comunque l'item. Se però i punti da risolvere sono troppi, troppo gravi o troppo dispendiosi in termini di tempo, allora l'item scelto dal Product Owner dovrebbe essere temporaneamente accantonato.

Task e ore

Dopo che un item è stato selezionato, i membri del team discutono il lavoro correlato e individuano i Task (compiti) necessari per consegnare il Product Backlog Item. Nel frattempo o subito dopo, il team stima quanto tempo (ore) sarà necessario approssimativamente per i singoli Task.

Non aspettarti però che il team fornisca una stima per ogni Task. Non è solo impossibile, ma anche non necessario.

I membri del team dovrebbero semplicemente stimare abbastanza Task da avere la sensazione di aver riflettuto su tutto a sufficienza. Perché questo è il vero obiettivo di un tale meeting. Definire Task e ore è secondario.

La domanda sui Commitment

Non appena i membri del team hanno definito i Task e possono stimare approssimativamente quanto tempo impiegheranno per determinati Backlog Item, dovrebbero porsi la domanda: "Possiamo dare un Commitment per questo?"

Trovo importante che il team si ponga questa domanda da solo e che non sia lo Scrum Master a chiedere: "Potete dare un Commitment per questo?" Perché così si impegnano gli uni verso gli altri, e non verso lo Scrum Master.

Non so come sia stato per te, ma i miei primi anni di lavoro (prima di Scrum) erano caratterizzati da Commitment non mantenibili verso superiori che chiedevano "Riesci a farcela?" ma in realtà intendevano "Fai in modo di farcela!"

Anche se lo Scrum Master viene chiamato "Master", non è un superiore del team e non dovrebbe nemmeno dare questa impressione. È meglio non essere visti come un capo che insiste sull'adempimento di tutti i Commitment.

Piuttosto, un team dovrebbe essere portato a chiedersi: "Possiamo dare un Commitment?" Perché un Commitment è molto più forte quando il team si impegna verso se stesso.

Inoltre, è chiaro che alla domanda del team "Possiamo dare un Commitment?" ci possono essere solo due risposte possibili: "Sì, possiamo" o "No, non possiamo." Se invece lo Scrum Master chiede "Potete dare un Commitment?", alcuni membri del team risponderanno con "noi" e altri con "io".

Scrum richiede un Commitment dell'intero team: "Se hai bisogno di aiuto, ti aiuterò e so che tu faresti lo stesso per me." e non "Questi sono i miei Task e quelli sono i tuoi."

Ripetere il processo per le Story successive

Se il team concorda di non poter dare un Commitment per un determinato Product Backlog Item, ne seleziona un altro e ripete il processo: Task – Ore – Commitment, fino a quando qualcuno dice di non poter dare un Commitment per l'item selezionato.

Quando succede, i membri del team discutono la situazione e verificano se magari qualcun altro può aiutarli. Forse un amministratore di database con conoscenze rudimentali di JavaScript può dare una mano a uno sviluppatore JavaScript sovraccarico.

Se questo non è possibile, la Story può essere rimandata nel Backlog e si può scegliere un item più piccolo o più semplice per cui tutti possano dare un Commitment.

E gli Story Point e la Velocity?

Forse hai già notato che in questo processo finora né gli Story Point né la Velocity hanno avuto un ruolo. Raccomando ancora di stimare i Product Backlog Item con l'aiuto degli Story Point. Tuttavia, Story Point e Velocity non hanno un ruolo significativo nello Sprint Planning orientato al Commitment fino a questo punto. Un ruolo importante lo giocano però nell'ultima fase di un meeting di Sprint Planning.

Verifica di plausibilità dei Commitment

Non appena il team ha riempito il tempo disponibile in uno Sprint, lo Scrum Master può verificare quanti Story Point hanno ricevuto i singoli item precedentemente. Comunica il risultato al team. Il team può quindi confrontare questo numero con la propria Velocity media o attuale.

Supponiamo che un team con una Velocity media di 20 tenga un tale meeting di Sprint Planning e selezioni item per un totale di 19 Story Point. Hanno selezionato questi item senza sapere con quanti Story Point erano stati valutati in precedenza.

Quando lo Scrum Master comunica loro che hanno appena selezionato item per un totale di 19 punti e che la loro Velocity media è uguale o molto simile, i membri del team possono presumere di aver pianificato la giusta quantità di lavoro per lo Sprint.

Se però sono stati selezionati item per un totale di soli 11 Story Point, dovrebbero chiedersi perché ora considerano il lavoro così più difficile.

Questo potrebbe essere dovuto al fatto che durante lo Sprint Planning hanno identificato del lavoro che prima non avevano considerato. Oppure constatano semplicemente che una Story è in realtà più complicata di quanto pensato.

In ogni caso, il team saprà se ha scelto una quantità adeguata di lavoro o se magari può pianificarne ancora di più.

D'altra parte, i membri del team si chiederanno cosa non hanno considerato se hanno selezionato item per un totale di 30 punti, cioè 10 in più della loro media. La domanda potrebbe essere: "Perché questo lavoro sembra così più facile dopo lo Sprint Planning rispetto a prima?"

Velocity e Story Point non hanno quindi un ruolo per la maggior parte di un meeting di Sprint Planning orientato al Commitment. Sono però indispensabili quando si tratta di verificare e confermare la pianificazione.

Un Commitment non è una garanzia

È importante non vedere mai un Commitment come una garanzia. Come disse Clint Eastwood in uno dei suoi film: "Se vuoi una garanzia, comprati un tostapane!"

Il Commitment di un team significa che tutti danno il meglio di sé. Se riescono a mantenere i loro Commitment nell'80 percento dei casi, è una buona media. Significa anche che prendono la cosa sul serio e utilizzano il tempo in modo ottimale. Questo crea fiducia nel team e in ciò che dichiara di poter realizzare.

Non dovrebbe però essere l'obiettivo portare sempre tutto al 100 percento di completamento. Un team che viene forzato a completare sempre tutto riuscirà a farlo, ma solo abbassando i propri Commitment.

Ho chiamato questo approccio "Sprint Planning orientato al Commitment". Viene però anche chiamato "pianificazione basata sulla capacità". Questo termine mi piace sempre di più, perché un Commitment può facilmente essere frainteso come una garanzia.

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