Chi decide la durata dello Sprint?

Una considerazione importante in un team Scrum è quanto dovrebbero durare gli Sprint. Se sono troppo lunghi, possono verificarsi troppe fluttuazioni. Se sono troppo corti, un team potrebbe non riuscire a completare lavori importanti o dover abbassare la propria Definition of Done per riuscire a completare i lavori.

Chi determina la durata dello Sprint?

Naturalmente la risposta è: l’intero team. E questi sono lo Scrum Master, il Product Owner e i membri del team (programmatori, tester, designer, ecc.).

Ma cosa succede quando tutte queste persone non riescono a mettersi d’accordo?

Discuteranno all’infinito finché non prenderanno finalmente una decisione comune?
No. Alla fine è lo Scrum Master che può stabilire la durata di uno Sprint.

Lo Scrum Master ha l’ultima parola sulla durata dello Sprint

Un buon Scrum Master farà di tutto per trovare una soluzione condivisa. Ma quando ha esaurito tutte le sue possibilità e non si intravede ancora un accordo, deve prendere una decisione.

Questo non dovrebbe accadere troppo spesso. Spero che la maggior parte degli Scrum Master non debba mai dire: “Ho ascoltato tutte le opinioni, ma faremo come dico io.” Dato che lo Scrum Master è però responsabile del processo all’interno di un team, spetta a lui la decisione finale.

Un esempio di perché una durata dello Sprint breve sia positiva

Ho seguito una volta un team che lavorava con Sprint di quattro settimane. I membri del team avevano difficoltà a inserire la giusta quantità di lavoro nei loro Sprint. Nei sei mesi precedenti al mio arrivo nel team, in ogni Sprint circa un terzo del lavoro veniva abbandonato.
Era un buon team che faceva un lavoro eccellente. I membri del team semplicemente non sapevano quanto lavoro potessero fare in quattro settimane. Il loro ottimismo li portava a prendere costantemente commitment troppo elevati.

Ho chiesto al team di riflettere su una soluzione al problema e di comunicarmi i risultati il giorno dopo. Ero entusiasta quando il giorno dopo mi è stato comunicato che sicuramente doveva essere cambiata la durata degli Sprint. “Sì”, dissi, “assolutamente!”

I membri del team erano sollevati dal mio consenso e dissero:

“Wow! Non pensavamo che ci avresti permesso Sprint di sei settimane!”

Dovetti comunicare loro che ero d’accordo nel cambiare la durata dello Sprint, ma che sarebbe stato meglio accorciarla anziché allungarla.

Alla fine abbiamo fatto quello che io – come Scrum Master consulente – avevo suggerito e abbiamo accorciato la durata dello Sprint.

Perché dovrebbe essere lo Scrum Master a decidere la durata dello Sprint?

Il team stava già inserendo il lavoro di sei settimane in uno Sprint di quattro settimane. Se il team avesse avuto Sprint di sei settimane, avrebbe sicuramente inserito otto o nove settimane di lavoro.

Quindi i membri del team dovevano imparare quanto lavoro sta in uno Sprint (indipendentemente dalla sua durata). Come Scrum Master chiamato come consulente, potevo riconoscere tutto questo più facilmente di quanto potessero fare loro stessi.

Vorrei sottolineare ancora una volta che cose del genere dovrebbero essere fatte solo in casi eccezionali. Posso contare sulle dita di una mano quante volte ho preso una decisione del genere dopo che un team non riusciva a trovare un accordo. Passare sopra a un team su qualcosa di così importante come la durata di uno Sprint dovrebbe avvenire solo con grande cautela. Ma alla fine si tratta del rispetto del processo e questo è responsabilità dello Scrum Master.

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