Scrum poker per team Scrum
«Dopo la daily facciamo dieci minuti di scrum poker»: in molti team Scrum si chiama così il planning poker, ed è lo stesso gioco. Carte scelte in segreto, scoperte tutte insieme, e una discussione quando i numeri non coincidono. Le regole e un giro completo d’esempio sono nella guida al planning poker. Dentro Scrum, però, nascono domande diverse: in quale evento conviene stimare, chi vota, cosa fa lo Scrum Master mentre gli altri giocano, e in quali casi la stima si può anche saltare.
La Scrum Guide non chiede story point
In parecchie aziende la stima in punti arriva come un obbligo: il PMO vuole la velocity di ogni team «perché in Scrum si fa così». Vale la pena controllare. La Scrum Guide chiede due cose soltanto: che gli elementi del Product Backlog vengano raffinati fino a stare in uno sprint, e che a dimensionarli siano i Developers che faranno il lavoro. Unità di misura e tecnica restano scelte del team. Di story point, velocity o carte non c’è traccia.
Punti e velocity sono entrati nei team Scrum più tardi, soprattutto da Extreme Programming, e oggi sono così diffusi che molti li considerano parte del framework. Non lo sono, e saperlo cambia il tono delle discussioni. Se il team decide di stimare in giorni ideali, con le taglie delle magliette o di non stimare affatto, resta in regola con Scrum; il PMO dovrà trovare un altro modo per leggere l’avanzamento.
Il posto per rimettere in discussione la stima è la retrospettiva. Se le sessioni sono diventate un rito che nessuno difende più, lì il team può decidere se cambiarle, ridurle o smettere.
Quando stimare: refinement o Sprint Planning
Prendiamo un team che sviluppa un gestionale per piccole imprese. Nel backlog c’è la storia «inviare automaticamente allo SdI le fatture emesse dal modulo vendite». Al primo voto qualcuno gioca «?»: nessuno sa se il cliente vuole passare dal proprio intermediario o collegare il gestionale direttamente al Sistema di Interscambio, e le due strade hanno dimensioni molto diverse.
Se questa scena avviene durante il refinement, con la storia ancora a due settimane dallo sprint, non è un problema. Il product owner scrive al cliente, la risposta arriva in qualche giorno e la storia torna al refinement successivo pronta per essere stimata. È il motivo per cui la maggior parte dei team stima lì: le sessioni di refinement (qualcuno le chiama ancora grooming) hanno proprio lo scopo di rendere le storie chiare e abbastanza piccole, e c’è il tempo per spezzare quelle che si rivelano enormi.
Se invece la stessa scena avviene nello Sprint Planning, il team ha due scelte scomode: lasciare fuori la storia all’ultimo momento, oppure metterla dentro con un numero inventato. Lo Sprint Planning funziona bene quando le stime ci sono già. Il team somma i punti delle storie candidate, li confronta con la velocity degli ultimi sprint e decide cosa entra. Si ristima solo quando nel frattempo è cambiato qualcosa. I team che fanno tutta la stima in quella riunione di solito la vivono come la più lunga dello sprint, e verso la fine le carte scendono sui numeri che fanno chiudere prima.
Chi vota
Votano i Developers, cioè chi realizzerà la storia, compresi tester e designer se fanno parte del team. Nella maggior parte dei team il product owner non vota: spiega, risponde, a volte chiarisce un criterio di accettazione durante la discussione. Lo Scrum Master vota solo se lavora anche lui sulle stesse storie. Un responsabile che partecipa per curiosità farebbe bene a restare in ascolto, perché il suo voto, per quanto ben intenzionato, pesa più degli altri.
Cosa fa lo Scrum Master
Quando non sviluppa, lo Scrum Master non gioca carte. Facilita, e nella pratica questo vuol dire intervenire in poche situazioni precise.
Il product owner anticipa la risposta. «Questa è semplice, è solo un campo in più» detto prima del voto è un’ancora a tutti gli effetti. Lo Scrum Master può chiedere al product owner di descrivere il bisogno dell’utente e lasciare la valutazione a chi vota.
Qualcuno annuncia il proprio numero. Basta un «per me è un 3» a mezza voce per condizionare il giro. Si riparte con un nuovo giro, senza farne un dramma, e di solito il team impara in fretta.
I voti dei nuovi arrivati coincidono sempre con quelli del tech lead. Può essere una coincidenza, ma se succede sessione dopo sessione vale la pena notarlo. Chiamare per primi, a ogni scoperta, il voto più alto e quello più basso, chiunque li abbia dati, rende normale essere fuori dal coro.
La sessione non arriva in fondo alla lista. Succede quasi sempre, e il lavoro dello Scrum Master comincia prima della riunione. Con il product owner mette in cima le storie che servono nel prossimo sprint, così un refinement interrotto a metà lascia fuori quelle meno urgenti. Le storie con una domanda aperta nota in anticipo non vanno proprio al voto: prima serve la risposta. Durante la sessione, quando una storia si incaglia, si applica la regola dei due giri spiegata nella guida al planning poker.
Dopo la sessione resta un compito poco visibile: rileggere con il product owner le domande rimaste aperte e verificare che ognuna abbia un responsabile. Senza questo passaggio, le stesse storie tornano al refinement successivo con gli stessi dubbi.
Quando esce «?» o ☕
Entrambe le carte meritano una risposta vera: «?» segnala che manca un’informazione, ☕ che il team ha bisogno di una pausa. Come trattarle, e cosa fare quando «?» ricompare sempre sulla stessa storia, è spiegato nella pagina sulla sequenza di Fibonacci.
Storie con una scadenza esterna
Capita spesso che una storia arrivi con una data imposta da fuori: l’Agenzia delle Entrate aggiorna le specifiche tecniche della fattura elettronica, un bando regionale chiude a fine mese, cambia una norma sulla privacy. La tentazione è abbassare la stima per farla stare nella data. Gli story point però descrivono quanto è grande il lavoro, e l’urgenza non lo rimpicciolisce. Se una storia da 13 deve uscire in questo sprint, la conversazione giusta con il product owner riguarda cosa togliere dallo sprint per farle spazio. Trasformare quel 13 in un 5 sposta solo il problema alla fine dello sprint.
Scrum poker e velocity
Quasi tutti i team stimano in punti per avere una velocity, cioè i punti completati in uno sprint, da usare per decidere quanto lavoro prendere nel successivo. Come si calcola e come si usa per le previsioni è spiegato nella guida agli story point.
Quando se ne può fare a meno
La domanda da farsi è chi legge le stime, e per decidere cosa. Se nessuno le usa, né nello Sprint Planning né per rispondere a un cliente, le sessioni di stima costano ore senza dare nulla in cambio. Prima di continuare a produrle, conviene decidere in retrospettiva a cosa devono servire.
Un team di due o tre sviluppatori che lavora su un solo prodotto, con un product owner che non deve promettere date a nessuno, spesso se la cava parlando delle storie senza votarle. Quando le storie sono tagliate tutte piccole e simili, basta contarle: se negli ultimi sprint ne sono state chiuse tra nove e dodici, se ne prende una decina.
Per un team di assistenza, con ticket che arrivano ogni giorno e vanno chiusi in fretta, votare ogni ticket ha poco senso. Gli serve di più sapere quanti giorni passano in media dall’apertura alla chiusura, ed è un dato che il sistema di ticketing fornisce già. Lo stesso vale per molti team che lavorano a flusso continuo, per esempio in Kanban.