Come si gioca a planning poker

Di poker, il planning poker ha solo le carte. Non si vince e non si bluffa: si cerca un numero su cui tutto il team sia d’accordo, e lo si cerca in un modo preciso. Si discute la user story, ognuno sceglie una carta senza mostrarla, le carte si girano nello stesso momento e, se i valori sono lontani, chi ha votato più alto e chi ha votato più basso spiegano il perché. Poi si rivota. È una delle tecniche di stima agile più diffuse, e oggi la si gioca spesso online, con metà del team in call.

Da dove viene

L’antenato è il metodo Delphi, messo a punto alla RAND Corporation tra gli anni Cinquanta e Sessanta per raccogliere previsioni da gruppi di esperti. Gli esperti rispondevano in forma anonima, ricevevano un riepilogo delle risposte degli altri e correggevano la propria stima nel giro successivo. Negli anni Settanta Barry Boehm e John Farquhar lo adattarono alla stima del software con il nome di Wideband Delphi, e la novità principale era la discussione aperta fra un giro e l’altro.

Il planning poker vero e proprio arriva nel 2002, con un breve articolo di James Grenning. Voleva stimare durante la pianificazione di una release XP senza che la riunione si trascinasse per ore. Il suo mazzo era diverso da quello di oggi: la sequenza con 20, 40 e 100 si è affermata più tardi, come racconta la pagina sulla sequenza di Fibonacci. A far conoscere la tecnica a un pubblico ampio è stato soprattutto Mike Cohn, che la descrive in Agile Estimating and Planning (2005), in una sezione del capitolo sulle tecniche di stima, e che ha stampato e distribuito i suoi mazzi di carte.

Le regole passo per passo

Un giro tipico funziona così:

1. Tutti hanno lo stesso mazzo, di solito 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, con in più «?» e la tazzina di caffè. I numeri sono quasi sempre story point.
2. Il product owner presenta la storia: chi è l’utente, cosa gli serve, quali sono i criteri di accettazione.
3. Il team fa domande sul perimetro: cosa è incluso, cosa resta fuori, cosa esiste già. Le domande su come implementare si annotano per dopo.
4. Ognuno sceglie una carta senza mostrarla. Niente commenti del tipo «io starei basso».
5. Si scoprono le carte nello stesso istante.
6. Se i voti sono vicini, si sceglie il valore e si passa oltre. Un 5 e tre 8 di solito diventano 8 dopo mezza frase.
7. Se sono lontani, parlano prima il voto più alto e quello più basso, poi si rivota.

Le carte le gioca chi farà il lavoro. Il product owner, nella maggior parte dei team, risponde alle domande ma non vota; chi vota in un team Scrum, e perché, è discusso nella pagina sullo scrum poker.

C’è poi una regola che conviene decidere in anticipo: al massimo due giri. Se dopo il secondo le carte sono ancora sparse, non se ne esce con un terzo voto. Le strade sono due: spezzare la storia in parti più piccole, oppure rimandarla al prossimo refinement con una domanda precisa e una persona che si impegna a trovare la risposta.

Un giro d’esempio: un 3 e un 13

Un team lavora al portale dei servizi online di un comune di medie dimensioni. In cima al backlog c’è questa storia: «Come cittadino voglio accedere all’area riservata con SPID o con la CIE, così non devo più usare le credenziali del vecchio portale.»

La product owner, Chiara, spiega che il comune vuole spegnere entro l’anno le vecchie credenziali rilasciate allo sportello. Arriva una sola domanda: i dati del cittadino vanno ripresi dall’anagrafe? Sì, tramite il codice fiscale, come già succede per i pagamenti.

Votano in cinque. Le carte scoperte sono 3, 3, 5, 8, 13.

Il 13 è di Elena, uno dei due 3 è di Davide. Chiara chiede a entrambi di spiegarsi, cominciando da Elena, che ha il voto più alto.

Elena: «Per SPID il lavoro è poco, d’accordo. Ma la CIE ha un flusso suo, con la registrazione del nostro servizio come fornitore, i metadati da far approvare e un ambiente di collaudo separato. Per un altro ente l’approvazione ci ha bloccati per settimane.»

Davide: «Io pensavo solo a SPID. Il comune ce l’ha già sul portale dei pagamenti, quindi si tratta di riusare quella configurazione, aggiungere il pulsante e fare la mappatura sul codice fiscale.»

Nessun altro aveva considerato la CIE come un lavoro a parte. Chiara conferma che è obbligatoria, ma che non deve per forza uscire nello stesso sprint. Il team allora propone di dividere la storia in due, e Chiara accetta.

Sulla parte SPID il nuovo giro dà 3, 3, 3, 5, 3, e la storia entra nel backlog a 3. Sulla parte CIE escono 8, 8, 5, 8, 8: la stima è 8, con una nota sull’approvazione esterna, che nessuna stima copre e che va chiesta subito. Se Davide avesse detto «è una cosa da niente» prima del voto, la storia sarebbe forse entrata nello sprint a 3, per poi fermarsi a metà in attesa di un’approvazione di cui nessuno sapeva nulla.

Gli errori più comuni

L’ancoraggio

L’ancora più ovvia è un numero detto prima del tempo. Quelle più insidiose sono frasi senza numeri: «tanto il form c’è già», «il cliente la vuole per venerdì», «l’altra volta ci abbiamo messo poco». Esiste anche un’ancora meno visibile: la storia appena stimata. Dopo tre storie da 8 di fila, la quarta tende a prendere 8 anche quando è diversa. Se te ne accorgi, confronta la storia con quelle di riferimento del team invece che con l’ultima votata.

Il peso dei senior

Il primo giro è protetto dalle carte coperte. Il secondo lo è meno: tutti hanno appena visto la carta del tech lead, e chi è in azienda da poco tende a spostarsi lì, anche quando la discussione non l’ha convinto. Sostenere un 13 davanti al collega che ha scritto metà del codice richiede coraggio. Aiuta che il tech lead, se il suo voto non è tra quelli estremi (che parlano sempre per primi), spieghi il proprio per ultimo, dopo aver ascoltato gli altri. Aiuta anche una domanda semplice di chi facilita, quando qualcuno cambia carta tra un giro e l’altro: «cosa ti ha fatto cambiare idea?». Se la risposta è un’alzata di spalle, vale la pena riparlarne.

Stimare una storia che non è pronta

Succede quando la storia arriva al tavolo con criteri di accettazione ancora da scrivere, o con una dipendenza da un altro team che nessuno ha verificato. Il product owner risponde «vediamo dopo» a una domanda su tre. Qui la carta giusta è «?», e la storia torna al refinement: un 5 dato alla cieca finisce comunque nel calcolo della velocity, come se fosse una stima vera. Come gestire «?» e ☕ è spiegato nella pagina sulla sequenza di Fibonacci.

Fare la media

Su una scala che cresce a salti, un solo voto alto sposta la media di molto: con 3, 5 e 40 si arriva a 16, una carta che nel mazzo nemmeno esiste. La mediana resiste meglio, ma nessuna delle due va copiata sul ticket quando le carte sono lontane. Entrambe riassumono un disaccordo che il team non ha ancora capito, e il 40 potrebbe essere l’unico voto informato del giro.

Planning poker da remoto

In call viene spontaneo dire «scrivete il numero in chat». Il risultato è che il primo a premere invio condiziona chi sta ancora digitando, e il voto coperto sparisce. Serve invece una stanza condivisa in cui si vota in privato e le carte si girano insieme.

La discussione resta in call, a voce; nella stanza si vota soltanto. Mentre si aspetta, la stanza mostra chi ha già scelto, così chi facilita sa quando scoprire le carte senza fare l’appello. SprintPoker funziona così, nel browser e senza account; cosa fa e cosa non fa è scritto nella pagina chi siamo.

Qualche abitudine aiuta:

• Nelle riunioni ibride votano tutti dal proprio dispositivo, anche chi è in sala riunioni. Se a Milano si alzano le carte fisiche e da Bari si vota online, i due gruppi non scoprono nello stesso momento, e chi sceglie per ultimo ha già visto i numeri degli altri.
• Decidete prima chi scopre le carte. Di solito è chi facilita, così nessuno preme il pulsante mentre un collega sta ancora leggendo la storia.
• Tenete la storia condivisa a schermo per tutto il giro, non solo mentre la si legge. Chi rientra da un’interruzione ritrova il testo senza doverlo chiedere.