Planning poker, migliora la tua stima dei requisiti

Il planning poker è il metodo più utilizzato per la stima agile di requisiti. È anche conosciuto con il nome di Agile poker o Scrum poker, anche se Scrum non definisce alcuna tecnica specifica per la stima delle user story.

Il planning poker in breve

Il planning poker è un metodo che si basa sulla dimensione relativa di un requisito in termini di impegno (effort in inglese) previsto per l’implementazione dello stesso. L’unità di misura utilizzata per la stima sono gli story point, abbreviato con SP.

Si gioca a planning poker in gruppo; si raggiunge la stima di ciascuna attività sfruttando il principio della “saggezza della folla” e all’unanimità (consensus). Il risultato, espresso in effort necessario all’implementazione di una funzionalità, è concettualmente molto vicino a un’indicazione di tempo piuttosto che di complessità, dato che ciò che conta per gli stakeholder, e dal punto di vista del business, è il time to market.

Come si gioca al planning poker

Nel caso di Scrum, Product Owner e Scrum Master, a meno che non siano a loro volta sviluppatori, non partecipano attivamente alle stime ma facilitano il processo. Ogni membro del team di sviluppo ha in mano un mazzo di carte con una sequenza di numeri. La sequenza raccomandata, ricavata dalla Successione di Fibonacci, è la seguente:

0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

In alternativa puoi anche utilizzare la sequenza originale dei numeri di Fibonacci o le taglie delle T-Shirt: XS, S, M, L, XL, eccetera. Io personalmente utilizzo le T-Shirt per stime più ad alto livello e quando ho pochissime informazioni sui requisiti, come in fase di definizione della Roadmap. Non amo utilizzare la sequenza originale di Fibonacci perché include numeri troppo “specifici” come 21, 34, 55, che danno una falsa idea di dettaglio.

Per la pianificazione dello Sprint Backlog, io e il mio team usiamo la sequenza raccomandata. In molti mazzi di carte per l’agile poker puoi anche trovare carte aggiuntive come nella figura qui sotto.

poker planning

Il simbolo di infinito (∞) è una chiara indicazione che la user story andrebbe divisa in parti più piccole per poter essere stimata, ma va da sé che anche punteggi troppo alti potrebbero indicare la stessa necessità. Il punto interrogativo è una richiesta di maggiori informazioni; la tazzina di caffè indica che si è a corto di carburante.

Come si gioca quindi? Il primo step è definire una baseline: si sceglie una user story dal backlog e la si analizza insieme al fine di definirne una stima dell’effort. Alla fine dell’articolo cercherò di fare un po’ più di chiarezza su cosa si intende per effort.

Il committente, o il Product Owner se si lavora con Scrum, introduce brevemente l’attività da svolgere. Quando tutti hanno un’idea abbastanza chiara su come procedere per la parte di implementazione, il moderatore (in Scrum lo Scrum Master, in altre metodologie agili può essere un membro del team) invita i partecipanti a scegliere una carta dal proprio mazzo e a mostrarla tutti insieme. Il conto alla rovescia è un metodo efficace.

Showdown!

È importante che  le carte vengano mostrate tutte insieme e che in fase di discussione del requisito non si faccia riferimento ai valori delle carte. In caso di discrepanze il gruppo riprende la discussione sul requisito cercando di capire i diversi punti di vista e i motivi che hanno portato a valutazioni discordanti.

Una volta chiariti i dubbi, ciascuno sviluppatore ripete la stima scegliendo una nuova carta dal mazzo, o quella mostrata in precedenza in caso volesse confermare la propria stima precedente. Si procede così fino a quando il team non raggiunge il consensus, ovvero l’unanimità, e tutti – o quasi – mostrano la stessa carta. Il moderatore può negoziare il consenso se la discussione rischia di inoltrarsi fino a notte fonda.

Una volta terminato il primo giro si procede con la stima delle restanti user story seguendo lo stesso identico procedimento. Se si è scelto il “form di registrazione al sito” come baseline e il team ha identificato l’effort come 5 SP, quando si discute l’effort delle attività successive si ha un riferimento abbastanza preciso. Per esempio: il “form di login” richiede lo stesso effort rispetto al “form di registrazione”? Oppure circa la metà, o il doppio? E così via per tutte le user story rimanenti.

Puoi ridefinire la baseline a ogni Sprint Planning o utilizzare sempre la stessa: in questo caso è importante che tutti gli sviluppatori abbiano ben chiari i dettagli dell’implementazione di quel determinato requisito. Puoi anche non definire alcuna baseline se preferisci, e valutare story per story, ma ti consiglio vivamente di sceglierne una e cambiarla soltanto in caso di cambiamenti nel team di sviluppo. Così facendo potrai avere un’indicazione più precisa su qual è la velocity del tuo team.

processo planning poker

agileway.it – creative commons con attribuzione.

Effort: tempo impiegato, non solo complessità

Come fa notare Mike Cohn in un suo articolo del 2010 (It’s Effort, Not Complexity), bisogna stare attenti a non cadere nella trappola della “complessità”: se si ha un team composto da un bambino e un chirurgo, e il backlog ha come attività un’operazione al cervello e l’appiccicare mille francobolli, i due task dovrebbero avere lo stesso numero di story point, dal momento che il tempo impiegato dovrebbe essere presumibilmente lo stesso.

La complessità è solo uno dei fattori, non quello determinante, e l’effort espresso dagli story point rappresentano un’unità di tempo.

L’esempio qui sopra, come dice Cohn, presume anche che sia la persona giusta a fare il lavoro giusto: ovvero il bambino lecca i francobolli e il chirurgo opera il cervello, non l’opposto. Dato che nella realtà può capitare che la persona sbagliata esegua il compito sbagliato, magari non in maniera così “drammatica” come nell’esempio di Cohn, conviene sempre tenere in considerazione nell’equazione rischio e incertezza, e non soltanto la complessità, quanto si effettua una stima.

Riassumendo con una formula:

SP = f(C, R, I)

Gli story point (SP) sono un’unità di tempo e sono il risultato della funzione che ha come variabili: complessità, rischio e incertezza.

Se sei alle prime armi con questo metodo, fai attenzione però a non confondere gli story point con le ore di lavoro. Determinare che una feature impiega 8 SP (story point) non significa dire che è pronta in 8 ore di lavoro, ma vuol dire che richiede più tempo di una feature che è stata stimata 2 SP o 1 SP e meno tempo di una che è stata stimata 13 SP.

Immagine di copertina rilasciata via Creative Commons da fsse8info su Flickr.