Il Planning Poker è una tecnica di stima agile, tipicamente impiegata dai team Scrum per determinare la complessità relativa di un task o di una User Story.

Si tratta di un metodo di stima collaborativo perché incoraggia il dialogo e la discussione tra i membri del team, ed è utile a prevenire la sottostima o, al contrario, la sovrastima delle attività, che potrebbero influire negativamente sulla pianificazione del progetto. Inoltre, il Planning Poker aiuta a rafforzare la comprensione comune delle attività e a rendere più trasparente il processo di stima.

La tecnica fa uso di un mazzo di carte da gioco e utilizza come base per la stima una sequenza di numeri “adattata”, simile alla sequenza di Fibonacci, che riportiamo di seguito:

1, 1, 2, 3, 5, 8, 13 ,21…

La sequenza di Fibonacci è una successione di numeri interi positivi dove ogni numero è il risultato della somma dei due precedenti.

La serie tipicamente utilizzata per il Planning Poker è una versione revisionata della sequenza di Fibonacci:

(0, ½ , 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞)

Dove:

• 0 – indica uno sforzo minimo o inesistente;
• ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 – sono valori crescenti associabili ad impegno che a sua volta ha una dimensione crescente;
• ∞ – quando l’impegno richiesto stimato è maggiore di 100, si utilizza il simbolo dell’infinito (∞) per indicare che la User Story richiede uno sforzo troppo grande per essere stimato. In questo caso, si dovrà procedere con una preventiva scomposizione.

Come condurre una sessione di Planning Poker

Lo Scrum team apre la sessione individuando di comune accordo una User Story già stimata in passato e da utilizzare come base per il processo di stima che si sta avviando. Questa User Story dovrà essere “a basso sforzo” (o “low-effort”, come si usa dire nella pratica) e pertanto avrà un valore assegnato, in termini di story point, pari a 2.

Non sai cosa sono gli story point? Leggi qui.

Se non dovesse esistere una User Story già precedentemente stimata, il team potrà selezionarne una tra quelle ancora da stimare che, a suo avviso, è ben definita e a basso sforzo e a cui assegna un valore pari a 2.

A questo punto, ogni membro del team riceve un set di carte i cui valori rispecchiano la sequenza prima descritta.

E se il team è geograficamente dislocato o lavora in modalità smart working?

In tutti quei casi in cui la sessione di Planning Poker non può avvenire in un luogo fisico, è possibile utilizzare App come Scrum Poker (per Android) o Scrum Time – Planning Poker (per IOS) o ricorrere, in alternativa, all’utilizzo tool online come Scrum Poker Online.

A questo punto il team è pronto per entrare nel vivo della sessione di stima, che si apre con l’intervento del Product Owner, che selezionerà un elemento del Product Backlog e lo descriverà allo Scrum team.

Il team avvia una discussione per confrontarsi circa le caratteristiche della User Story, per cercare di esplorare tutti gli elementi utili per valutare nel modo più preciso possibile, l’impegno necessario per completarla. Anche in questa fase, può essere utile il contributo del Product Owner, se necessario.

Al termine del confronto, ogni membro del team seleziona in piena autonomia la carta il cui valore rappresenta la propria stima. Per evitare reciproche influenze, è importante che tutte le carte siano rivelate contemporaneamente.

Bene! Cosa accade ora?

Se tutti sono concordi circa il valore assegnato alla User Story, quel valore ne rappresenterà senza dubbio la stima.  In caso contrario, si procede con un ulteriore confronto, che coinvolgerà principalmente coloro i quali hanno attribuito i valori più alti e quelli più bassi. Seguirà quindi una nuova stima con la rivelazione contemporanea delle carte.

Questo processo verrà ripetuto fin a quando non si raggiungerà il pieno accordo tra tutti i membri del team. Solo a quel punto, il Product Owner selezionerà la User Story successiva.

È chiaro che se i membri del team utilizzano criteri di stima molto diversi tra loro, raggiungere l’accordo potrebbe essere difficile e questo allungherebbe inevitabilmente i tempi della sessione.  In questi casi, tutt’altro che rari, gioca un ruolo chiave lo Scrum Master in quanto moderatore del processo. Solitamente, se la stima oscilla tra due valori, ad esempio 5 e 8, lo Scrum Master interverrà associando alla User Story il valore più alto (nel nostro esempio il valore sarà 8).

Quando tutte le User Story sono state stimate, è consigliabile ripetere il processo per ricalibrare le stime. In questo secondo passaggio il team riesamina e confronta tutte le User Story che hanno un valore simile, con l’obiettivo di intercettare eventuali errori nella stima.

Il Planning Poker è quindi una tecnica di stima efficace e facile da utilizzare, che trova ampia applicazione soprattutto nei team Scrum che lavorano su progetti di sviluppo software. La tecnica, se utilizzata con il giusto approccio, aiuta a garantire una pianificazione precisa e realistica del progetto, favorendo la collaborazione e la comunicazione tra i membri del team.

Un’alternativa al Planning Poker: l’Affinity Estimating

L’Affinity Estimating è una variazione della tecnica del Planning Poker.

Prevede l’utilizzo di una superficie di lavoro, che può essere fisica o virtuale, organizzata in colonne, a ciascuna delle quali sarà assegnato un valore della sequenza (0, ½ , 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞).

Come per il Planning Poker, si parte da una User Story con valore pari a 2, che sarà inserita nella relativa colonna.

Per l’Affinity Estimating si può procedere in tre modi alternativi:

1. i membri del team selezionano in autonomia le User Story dal Product Backlog e, sulla base della propria opinione, le inseriscono nella colonna che ha valore pari alla loro stima. Una volta esaurito il Backlog, il team prenderà qualche minuto per rivedere le stime e spostare le carte che, secondo l’opinione individuale, sono state posizionate in modo errato. Lo Scrum Master, che funge anche in questo caso da moderatore, identifica le User Story che sembrano muoversi molto tra le colonne e le estrae. Queste storie vengono poi discusse collettivamente con il contributo del Product Owner, per ottenere il consenso sulla stima finale;
2. il Product Owner legge la User Story e chiunque può porre una domanda per chiarire i propri dubbi. Successivamente, la storia viene posizionata chiedendo l’accettazione da parte del gruppo. In caso di disaccordo, la User Story viene discussa ulteriormente ma entro un periodo di tempo prestabilito, ad esempio 60 secondi. Se il disaccordo persiste, la storia viene messa da parte e il processo viene ripetuto per la storia successiva. Quando tutte le User Story sono state stimate, quelle messe da parte vengono discusse fino al raggiungimento del consenso;
3. ogni membro del team, a turno, legge una User Story e propone una stima. In caso di dissenso la storia viene discussa fino al raggiungimento del consenso e così via.

Il Planning Poker e l’Affinity Estimating garantiscono un corretto bilanciamento fra il processo decisionale di gruppo e quello individuale, garantendo l’indipendenza di quest’ultimo ma promuovendo al tempo stesso una maggiore interazione e una migliore comunicazione fra i partecipanti e ciò le rende tecniche applicabili anche al di fuori dei contesti agili.