Il Planning Poker® è un metodo di stima usato prevalentemente nei contesti agile. Racchiude in sé elementi della stima comparativa e delle tecniche decisionali di gruppo, come la Delphi.
In un progetto che usa lo sviluppo agile, un team avrà bisogno di stimare il lavoro implicato in un certo numero di user story alle quale intende lavorare all’interno di un dato timebox (o sprint).
Il team comprenderà persone con differenti stili di stima, differenti livelli di esperienza e differenti competenze tecniche. Per ridurre il divario fra le stime e consentire a tutti di contribuire la processo di stima il primo principio del planning poker è quello di stimare in termini di “story point” anziché in ore o giorni.
Uno story point è una misura relativa della dimensione e complessità (da qui il collegamento con la stima comparativa). il team inizierà scegliendo una storia relativamente semplice a cui assegnerà il valore di 1.
Un esempio comunemente usato è la pittura di una parete. Si tratta di un lavoro relativamente semplice a cui verrà assegnato il valore di 1: questa rappresenta la storia “baseline”. Un pittore alle prime armi e un decoratore esperto possono impiegare tempi molto diversi per dipingere il muro, ma concorderanno sul fatto che si tratta di un lavoro semplice e chiaro. Inoltre saranno d'accordo sul fatto che dipingere due pareti varrà 2 story point. Possono anche essere d'accordo sul fatto che dipingere tutte e quattro le pareti di una stanza varrà solo tre story point, a causa delle economie di scala.
Per continuare con l’esempio pittorico, il team può anche dover considerare la pittura di una finestra. Questa attività richiede più preparazione ed un’attenta protezione del vetro. È più complesso della pittura di una parete e quindi gli può essere assegnato un valore di 2 story point.
Il processo ora ha bisogno di raccogliere opinioni da tutti i membri del team senza pregiudizi. È qui che le carte da "poker" vengono usate in un modo che ha delle somiglianze con il processo Delphi.
Viene distribuito ai membri del team un mazzo di carte da gioco che hanno valori liberamente basati sulla sequenza di Fibonacci (1,1, 2, 3, 5, 8, 13, …ogni carta successiva ha un valore pari alla somma dei valori delle due carte precedenti). La ragione per cui queste carte non sono in progressione lineare (1, 2, 3, 4, 5) risiede nel fatto che più un’attività è grande e complessa, più è difficile stimarla accuratamente.
La carta “infinito” può essere usata per indicare che lo stimatore non pensa che l’attività possa essere completata e il simbolo “?” viene usato se la persona non è in grado di fornire una stima.
Il processo inizia con l’esame di una user story (ad esempio dipingere una finestra) e con una breve discussione riguardo alle sue implicazioni. Dopo di che ognuno assegna privatamente un valore in story point (partendo dalla comparazione con la storia baseline). È importante che in questa fase le persone non si consultino fra loro. Viene poi chiesto a tutti i partecipanti di rivelare la propria stima mettendo contemporaneamente una carta sul tavolo. Ciò evita che la discussione sia eccessivamente influenzata dalla prima stima (situazione nota come ‘ancoraggio’ in cui le persone modificano la propria opinione sulla base di quella di altri).
Se tutte le stime rientrano nel valore di due carte consecutive (ad esempio tutti 3 e 5 o tutti 5 e 8), alla storia viene assegnato il valore più alto fra i due. Se invece il divario fra le stime è maggiore di quello normale, il facilitatore chiederà a qualcuno che ha fornito la stima più bassa e a qualcuno che ha dato la più alta di spiegare il proprio ragionamento.
Potrebbe essere, ad esempio, che la user story non dava indicazioni precise riguardo al tipo di finestra per cui i vari stimatori hanno fatto ipotesi diverse sulla complessità della finestra in base alla loro recente esperienza.
L'intervallo di stima può quindi essere ridotto chiarendo meglio la storia (qui è necessario consultare l'utente da cui parte l’esigenza) oppure cercando di raggiungere una comprensione comune e condivisa da tutto il team circa la complessità dell’attività e ripetere quindi il processo.
Ogni team che sviluppa user story entro un periodo di tempo predeterminato (timebox) avrà una ‘velocità’. Questa rappresenta il numero di story point che il team riesce di solito a completare entro un dato periodo (ad esempio 2 settimane). Per calcolare la velocità c’è bisogno chiaramente di una sorta di conversione degli story point in tempo (ore o giorni lavorativi). La velocità è una qualità intrinseca di un team e, all'inizio della fase di consegna di un progetto, essa rappresenta di per sé una stima. Man mano che vengono completati più timebox, ci sarà sempre maggiore sicurezza circa la velocità del team. Il team di gestione del progetto può poi eseguire grazie a ciò una pianificazione di più alto livello sulla base della stima in story point effettuata dai team di consegna.
Planning Poker® è un marchio commerciale di Mountain Goat Software.
Grazie a E-quality Italia e a Project Management Europa per la traduzione
