Errori e anti-modelli nel Planning Poker

La maggior parte delle sessioni di Planning Poker fallite è riconducibile a una breve lista di cause: raffinamento inadeguato, discussione influenzata da preconcetti, equiparazione dei punti alle ore e utilizzo della velocità come arma. Il rituale è sufficientemente solido da resistere a qualsiasi di queste cause nel corso di una singola sessione — a condizione che qualcuno nella sala se ne accorga. Ecco a cosa prestare attenzione, raggruppato in base al punto in cui si verifica il problema.

Nella sala: errori nelle votazioni e nella rivelazione dei risultati

Stima in ore

Il team inizia a convergere sugli equivalenti in ore: 3 corrispondono a mezza giornata, 5 a una giornata, 8 a un paio di giornate. Una volta che emerge questa corrispondenza, si sta effettuando una stima basata sul tempo con una patina di Fibonacci, e la proprietà di sforzo relativo che gli story point sono destinati a fornire viene meno. Riconcentratevi sulla storia di riferimento ed eliminate ogni riferimento alle ore per un ciclo. Se il team non riesce a condurre la conversazione senza tradurre in termini di tempo, il problema si trova solitamente a monte: uno stakeholder che crede solo nelle scadenze.

Si tratta semplicemente di calcolare la media delle carte

Qualcuno gioca un 3, qualcun altro un 13; il facilitatore divide il risultato a 8 e prosegue. Lo scopo della rivelazione simultanea era proprio quello di far emergere tale disaccordo; la media lo nasconde. In una distribuzione a un solo livello (3 e 5), si prende il numero più alto: non si tratta di calcolare una media, ma di optare per l’interpretazione più cauta. In una distribuzione a due o più livelli, si instaura un dialogo, non si risolve un problema aritmetico.

Vince il numero della persona più anziana

Le carte nascoste impediscono all’ingegnere capo di determinare l’esito del voto — ma non di porre fine alla discussione. Dopo la rivelazione, chi interviene per primo con sicurezza tende comunque a conquistare il consenso della sala. Chiedete a chi ha la carta più bassa di spiegare per primo, poi a chi ha quella più alta e infine a tutti gli altri. Le voci dei più giovani che riescono a dare il tono alla discussione sin dall’inizio mantengono il proprio contesto, anziché cedere il passo all’anzianità di servizio.

Si ripeterà la votazione finché tutti non si arrenderanno

Al terzo o quarto giro di votazione, il divario si riduce perché le persone sono stanche, non perché siano d’accordo. La stima che ne risulta è frutto di una negoziazione sociale, non di un consenso condiviso. Due votazioni per ogni storia rappresentano il limite massimo corretto. Si sta procedendo verso una terza votazione? La storia non è pronta: la si suddivida, la si rimandi in fase di perfezionamento oppure la si accanti. (Il ciclo in quattro fasi illustra la sequenza completa.)

Ignorare la carta “?”

Qualcuno lancia un? e il gruppo lo considera come un voto non valido — «qualcuno ha un dato concreto?» — anziché come un segnale di stop. Un? rappresenta un’informazione concreta: se qualcuno non è in grado di valutarne responsabilmente la portata, ciò significa solitamente che alla storia manca il contesto, oppure che non è ancora sufficientemente definita. Portatela alla luce. La notizia necessita di un’ulteriore discussione, non di un’altra revisione.

A margine della sessione: errori procedurali

Nessuna storia di riferimento

Il team effettua le stime senza un punto di riferimento, per cui alla domanda “cos’è un 5?” si risponde in modo diverso ad ogni sprint e i punteggi tendono a variare senza che nessuno se ne accorga. Scegliete una storia già consegnata come punto di riferimento e ridefinite il punto di riferimento ogni trimestre, oppure dopo cambiamenti significativi all’interno del team. Senza una storia di riferimento, la vostra velocità è un percorso casuale.

Stima preliminare prima del perfezionamento

La storia si riassume in due righe. Metà del team sta valutando “la versione in cui lo realizziamo correttamente” e l’altra metà “la soluzione minima che corrisponda alla descrizione”. Entrambe hanno ragione; nessuna delle due è ciò che verrà effettivamente consegnato. La soluzione non sta in una stima più rapida, bensì in un affinamento più graduale: criteri di accettazione, ambito di responsabilità, comprensione dei contorni, poi la stima. Stimare per capire quanto sia grande qualcosa, anziché farlo a posteriori, è il motivo per cui la stessa storia viene valutata 3 nella prima settimana e 13 nella terza.

Stima in contumacia

Il team valuta una storia il cui responsabile è “l’altro team” o “chiunque sia di turno quando viene assegnata”. Chiunque sia presente nella sala vota con sicurezza perché il lavoro non spetta a loro. Non stimare il lavoro di cui le persone presenti nella stanza non saranno responsabili. Se una storia supera i confini del team, coinvolgi rappresentanti di entrambi i team oppure dividila lungo il confine. Una stima fornita da persone che non svolgeranno il lavoro non è realmente una stima.

Sessioni che si protraggono oltre i 45 minuti

La qualità delle stime precipita dopo circa 45 minuti: le schede diventano più piccole, poi più grandi, e alla fine tutti si limitano a seguire l’esempio di chi conduce la sessione. Fissate un limite di tempo per la sessione, non solo per le storie, e interrompete dopo 45 minuti. Se c’è altro da valutare, programmate una seconda sessione oppure ricorrete a una tecnica più rapida come il «bucket sizing» per la coda lunga.

Stima dei bug con precisione a livello di funzionalità

“Indagare sul problema del danneggiamento dei dati” ottiene un 5, lo stesso punteggio di “aggiungere una casella di selezione alla finestra di dialogo di esportazione”. Nel primo caso l’ambito è noto; nel secondo, la natura stessa dell’attività consiste proprio nel fatto che non si sa cosa comporti. I bug e il lavoro esplorativo meritano solitamente un percorso distinto: un’indagine a tempo determinato di uno o due giorni, seguita da una storia di follow-up per correggere ciò che si riscontra. Inserirli a forza nel piano delle funzionalità significa fingere di disporre di informazioni che in realtà non si possiedono.

All’interno dell’organizzazione: errori di gestione

La velocità come indicatore di produttività

Un manager inizia a confrontare la velocità tra i vari team o a chiedersi perché questo sprint abbia raggiunto i 28 punti mentre l’ultimo ne aveva totalizzati 32. Nel giro di due sprint, ogni stima risulta superiore del 30%.

Inflazione dei punti storia

I punti aumentano progressivamente, sprint dopo sprint, senza che il carico di lavoro diventi più gravoso. Di solito ciò è dovuto a una delle tre cause seguenti: la velocità viene misurata esternamente (come indicato sopra), la storia di riferimento ha subito uno slittamento, oppure il team ha smesso di ricalibrare i propri parametri. Verifichatelo rivalutando cinque storie che avete consegnato un anno fa e osservando dove si collocano ora. Se risultano costantemente più grandi, la vostra scala si è spostata. (Maggiori informazioni in velocity.)

Tabella di conversione dei punti in ore

Qualcuno, con le migliori intenzioni, scrive sul wiki “1 punto = 4 ore”. All’interno di uno sprint, ogni discussione sulla stima si trasforma in una discussione, appena velata, in termini di ore, e la proprietà dello sforzo relativo viene nuovamente meno. Eliminate la tabella di conversione. Se uno stakeholder ha bisogno di una data, calcolatela in base alla velocità effettiva del team — punti per sprint moltiplicati per il numero di sprint — e non in base a un tasso fittizio di conversione da punti a ore.

Come si presenta il “buono”

Un team che gestisce bene il Planning Poker non evita tutte queste situazioni, ma le individua rapidamente. Il meccanismo è sufficientemente solido da consentire di recuperare da un singolo errore nel corso di una sessione, purché qualcuno presti attenzione alla distribuzione delle carte, al valore di riferimento e al tempo a disposizione.

Non conosce ancora questa tecnica? Inizi con cos’è il Planning Poker e come condurre una sessione. Oppure apra semplicemente una sessione e provi con una storia semplice prima che la prossima si riveli troppo complessa.

Domande frequenti

Quali sono gli errori più comuni nel Planning Poker?

Calcolare la media delle schede invece di discutere la dispersione, stimare in ore, lasciare che sia il numero indicato dalla persona con maggiore anzianità a determinare l’esito della discussione, ripetere la votazione fino a quando i partecipanti non si arrendono, effettuare stime prima della messa a punto e considerare la velocità come un indicatore di produttività. La maggior parte delle sessioni fallite è riconducibile a uno di questi fattori.

Perché calcolare la media degli story point è un errore?

La rivelazione simultanea serve a far emergere il disaccordo; il calcolo della media lo nasconde. Un 3 e un 13 non equivalgono a 8: significano che due persone stanno valutando situazioni diverse. In caso di scarto di un solo punto, si prenda il numero più alto; in caso di scarto maggiore, si avvii una discussione.

È sbagliato convertire gli story point in ore?

Sì. Nel momento in cui sul wiki viene indicato che 1 punto = 4 ore, ogni stima diventa una discussione sulla durata e la nozione di “sforzo relativo” viene meno. Se un stakeholder ha bisogno di una data, la si calcoli in base alla velocità del team, non a partire da una conversione per singola storia.

Quanto dovrebbe durare una sessione di Planning Poker?

Limitate la durata a circa 45 minuti. Dopo tale intervallo, la qualità delle stime cala drasticamente: le schede si spostano e i partecipanti iniziano a seguire ciecamente le scelte del capogruppo. Se il carico di lavoro arretrato è maggiore, programmate una seconda sessione oppure passate a una tecnica più rapida, come il “bucket sizing”.

Nel “planning poker” è opportuno ripetere la votazione?

Una volta, forse due. Al terzo giro di votazioni il divario si riduce perché le persone sono stanche, non perché siano d’accordo. Se si sta andando verso un terzo giro, il testo non è ancora pronto: lo divida o lo rimandi in fase di perfezionamento.