Planning poker: la strategia all-in per la stima Agile

Immagina di aver comprato una casa e di voler ristrutturare la cucina. Chiedi a un appaltatore una stima del tempo necessario per la ristrutturazione e del costo approssimativo. Ti fornisce una stima, ma due mesi dopo ti penti della tua decisione perché il progetto è andato ben oltre la tempistica e il budget originari. 

Quando hai l’opinione di una sola persona, hai solo il suo contributo e la sua esperienza da considerare. Tuttavia, quando si coinvolgono più persone con esperienze diverse, si ottiene una stima più completa e accurata del lavoro da svolgere.

Questa stima basata sul consenso è la base del metodo Agile Planning Poker. 

Che cos’è il planning poker?

Il planning poker è un metodo di stima che aiuta il tuo team Agile a prevedere l’impegno necessario per completare una user story in un product backlog. Spesso utilizzato nelle metodologie di gestione dei progetti Agile, a volte viene chiamato “Scrum poker” o “pointing poker”. La parola “poker” si riferisce alle carte che ogni membro del team utilizza durante il processo.

La storia del planning poker

Il planning poker si basa su una tecnica nota come Wideband Delphi. Wideband Delphi è un processo di stima basato sul consenso sviluppato a metà del XX secolo dalla RAND Corporation, un think tank senza scopo di lucro. 

James Grenning, autore di “The Manifesto for Agile Software Development”, ha perfezionato la tecnica Wideband Delphi nel 2002 e l’ha ribattezzata Planning Poker. È stato poi ulteriormente perfezionato e reso popolare da Mike Cohn nel suo libro del 2005, "Agile Estimating and Planning". 

Come funziona il planning poker

Il processo di planning poker avviene all'inizio del processo di pianificazione dello sprint, in modo che gli Scrum master e i product manager possano avere un'idea precisa di quanto lavoro può essere completato in ogni sprint. Ecco come funziona.

1. Crea le carte per il planning poker

Ogni membro del tuo team Scrum o Agile ha una presentazione di carte con valori diversi. Ogni carta avrà uno di questi valori: 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Questi numeri possono sembrare casuali, ma in realtà sono variazioni arrotondate della sequenza di Fibonacci. Questi valori rappresentano più comunemente gli story point. Tuttavia, alcuni team possono utilizzarli come stima basata sul tempo per il completamento di una user story. La stima basata sul tempo più comune è misurata in ore.

Il product owner o lo Scrum master fungerà da moderatore e leggerà una specifica user story dal backlog del prodotto o degli sprint. I membri del team hanno quindi l'opportunità di porre domande e chiarire i dubbi, se necessario, in modo che l'intero team possa avere un'idea precisa del lavoro da svolgere per quella specifica voce del backlog. 

Ecco alcune domande che il tuo team può porre per comprendere meglio una storia utente:

• Quali sono le diverse tecniche che possiamo usare per completare quella storia?

• Quante persone dovranno lavorare a questa storia?

• Come reagiranno gli stakeholder se ci saranno ritardi in questa storia?

2. Vota ogni storia utente

Una volta che il team ha terminato la discussione di una storia utente, ogni stimatore sceglie una carta che corrisponde alla quantità di impegno o di story point che ritiene correlati a quell'elemento del backlog. Tutti rivelano la propria carta contemporaneamente. Se tutti scelgono la stessa stima, questa diventa la stima ufficiale per quell'elemento del backlog. L'obiettivo è che tutti abbiano la stessa stima. 

3. Raggiungi un consenso

Se i membri del team hanno opinioni diverse sulle loro stime iniziali, il membro del team con la stima più alta e il membro del team con la stima più bassa si prendono del tempo per discutere il motivo per cui hanno scelto quel numero specifico. Una volta completata questa discussione, tutti selezionano nuovamente le proprie carte. Questo processo si ripete fino a quando il team non raggiunge un consenso. 

4. Pianifica lo sprint

Ora che tutti gli elementi nel tuo backlog hanno delle stime, è molto più facile pianificare con precisione uno sprint. Poiché tutto il team ha un consenso su quanto tempo richiederà ogni attività, è molto più probabile che tu sia in grado di adattare la giusta quantità di lavoro ai tuoi sprint.

Quando organizzare una sessione di planning poker

Il planning poker in genere si svolge subito prima del processo di pianificazione dello sprint, in modo che il product manager o lo Scrum master possano avere un'idea precisa del lavoro prima di pianificare uno sprint. Puoi utilizzare questo metodo di stima una volta per sprint: poiché gli elementi vengono continuamente aggiunti a un backlog degli sprint o del prodotto, dovresti avere una fornitura costante di elementi del backlog da inserire in ogni sprint. 

Se hai solo una piccola quantità di user story da discutere nel tuo product backlog, puoi combinare questa sessione alla fine di una riunione stand-up giornaliera, poiché tutti i membri del team sono già presenti. 

I vantaggi del planning poker

Il vantaggio principale del planning poker è che le stime del tuo team sono più accurate. Avere una stima accurata è una parte importante del processo di pianificazione dello sprint, perché offre sia al team che agli stakeholder una tempistica realistica per il completamento di un'attività.

Di seguito elenchiamo alcuni altri modi in cui il planning poker può avvantaggiare il tuo team Agile:

• Ogni membro del team ha voce in capitolo. Tutti i membri del team di sviluppo sono importanti e questo processo offre loro l'opportunità di far conoscere il proprio contributo. Questo può aiutare i membri del team a rimanere più coinvolti nel loro lavoro. 

• I membri del team hanno l'opportunità di discutere delle user story. Durante il processo di planning poker, il team di sviluppo ha l'opportunità di collaborare per discutere le user story prima che il lavoro inizi effettivamente. Questo aiuta le persone a essere sulla stessa lunghezza d'onda su come risolvere determinate user story, indipendentemente dallo sviluppatore assegnato a tale story. 

• Le stime delle attività sono relative ad altre attività. Quando il tuo team utilizza gli story point per rappresentare il numero sulla propria carta di planning poker, è più facile capire l’impegno richiesto da un’attività specifica in base ad altre attività nella pipeline. Ad esempio, una storia utente con una stima di 2 sarà molto più facile da completare rispetto a una storia utente con una stima di 40.

Pianifica il tuo sprint con uno strumento di gestione del lavoro

Mantieni il tuo team Agile in sintonia utilizzando uno strumento di gestione del lavoro. Asana ti aiuta a pianificare e organizzare i tuoi progetti Agile in uno strumento flessibile e collaborativo. Che il tuo team lavori in una Bacheca Kanban o in una cronologia più lineare, Asana offre le funzionalità per aiutare il tuo team Agile a creare rapidamente.