Cos'è la tecnica del planning poker?
Il planning poker è una tecnica di stima agile basata sul consenso che aiuta i team a dimensionare le user story attraverso una combinazione di processo strutturato e discussione aperta. È ampiamente utilizzato nei team Scrum durante le sessioni di pianificazione sprint e di refinement del backlog, e la sua combinazione di anonimato, rivelazione simultanea e dibattito strutturato lo rende uno dei metodi più efficaci per produrre stime oneste e condivise dall’intero team.
Il nome deriva dai mazzi di carte fisici originariamente utilizzati, che assomigliano alle carte da gioco — ma oggi la maggior parte dei team usa strumenti online che replicano le stesse dinamiche senza richiedere che tutti siano nella stessa stanza.
Le quattro fasi del planning poker
Fase 1: Leggere la user story
Il facilitatore — tipicamente lo Scrum Master — presenta una user story al team. Il Product Owner è disponibile per fornire contesto, rispondere alle domande e chiarire i criteri di accettazione. In questa fase, l’obiettivo è garantire che ogni partecipante abbia una comprensione condivisa di cosa implica la story prima che inizi qualsiasi stima.
Questa fase è spesso dove avvengono preziose discussioni pre-stima. I membri del team possono fare domande su casi limite, dipendenze o vincoli tecnici. Se una story è troppo vaga o indefinita per essere discussa in modo costruttivo, dovrebbe essere rimandato al Product Owner per ulteriore refinement piuttosto che stimata nell’incertezza.
Fase 2: Stimare in modo anonimo e indipendente
Una volta che il team ritiene di avere una comprensione sufficiente della story, ogni membro seleziona privatamente una carta dal proprio mazzo che rappresenta la sua stima della complessità relativa della story. I valori delle carte seguono tipicamente la sequenza di Fibonacci: 1, 2, 3, 5, 8, 13, 21, e talvolta valori più alti o carte speciali come ∞ (troppo grande per essere stimata) o ? (informazioni insufficienti).
Il requisito fondamentale in questa fase è che le stime vengano formate in modo indipendente, senza influenza degli altri membri del team. Nessuno condivide il proprio numero, nessuno fornisce indizi sulla propria carta, e il linguaggio del corpo rimane neutro. Questa indipendenza è ciò che rende efficace il planning poker — preserva la diversità delle prospettive che un approccio puramente basato sulla discussione eroderebbe.
Fase 3: Rivelare simultaneamente
Quando tutti hanno fatto la loro scelta, il facilitatore chiede la rivelazione. Tutti i membri del team mostrano le proprie carte nello stesso momento. Questa rivelazione simultanea è il meccanismo che previene l’ancoraggio — il bias cognitivo ben documentato in cui le persone aggiustano il proprio giudizio verso il primo numero che sentono.
Se tutte le stime sono identiche o molto vicine, il consenso si raggiunge rapidamente e il team registra la stima e passa alla story successiva. Se le stime variano in modo significativo, la sessione passa alla fase più importante.
Fase 4: Discutere fino al consenso
Quando le stime divergono, il team discute. I partecipanti che hanno dato le stime più alte e più basse vengono tipicamente invitati a spiegare prima il loro ragionamento. Questa discussione strutturata porta alla luce diverse assunzioni, rischi nascosti e lacune di conoscenza che potrebbero non emergere da una semplice discussione di gruppo.
Dopo la discussione, il team vota di nuovo. Questo processo si ripete finché il team non raggiunge una stima consensuale — o finché non decide di suddividere la story in pezzi più piccoli e gestibili e stimare ciascuno separatamente. L’obiettivo non è forzare l’accordo tramite compromesso, ma raggiungere una comprensione condivisa del lavoro.
Chi dovrebbe partecipare?
Il team di sviluppo forma il nucleo di una sessione di planning poker. Sono le persone che costruiranno effettivamente il prodotto, e le loro stime dovrebbero riflettere la loro comprensione collettiva della complessità tecnica coinvolta. Includere tutte le discipline rilevanti — sviluppatori, QA, UX e qualsiasi altro ruolo che contribuisce alla story — produce stime più accurate e complete.
Il Product Owner è presente ma di solito non vota. Il suo ruolo è definire cosa è necessario, rispondere alle domande e chiarire i criteri di accettazione. Avere il Product Owner disponibile in tempo reale riduce drasticamente il numero di story ambigue che devono essere rinviate per un refinement successivo.
Lo Scrum Master facilita la sessione — gestisce i tempi, supervisiona il processo e assicura che le regole (specialmente la rivelazione simultanea) vengano seguite. Uno Scrum Master efficace crea spazio per i membri del team più silenziosi per condividere le loro stime e previene che le voci dominanti orientino il gruppo prima che le carte vengano mostrate.
Perché il planning poker funziona
Il planning poker è efficace perché combina la saggezza collettiva con controlli di processo strutturati. Richiedendo stime private indipendenti prima di qualsiasi discussione di gruppo, cattura una gamma più ampia di prospettive rispetto a un semplice alzata di mano o a un approccio dall’alto verso il basso. Richiedendo una discussione ogni volta che le stime divergono, garantisce che i disaccordi vengano affrontati piuttosto che ignorati.
Il risultato sono stime che l’intero team comprende e fa proprie — il che è in definitiva più prezioso della previsione di un singolo esperto.