Story Point e Morra Giapponese!

Jankenpon!: si sente dal tavolo in fondo alla sala dove i componenti di un team stanno partecipando ad una cerimonia Agile.

Jankenpon!: ancora una volta dopo qualche minuto mani a pugno si alzano e nell’abbassarsi all’unisono tutte verso lo stesso punto mostrano una o più dita.

Segue una piccola discussione su un numero detto Story Point e poi si prosegue con un’altra schedina.

Sasso Carta Forbice
Lavorare divertendosi

Il Product Owner legge il titolo e la descrizione, aggiunge ulteriori dettagli relativi alla lavorazione e aspetta domande dal suo pubblico.

Jankenpon!: a chi vede il team tornare alle postazioni dal luogo in cui si erano riuniti sembra che ritornino dalla pausa dopo aver giocato alla morra giapponese.

Altri team usano Bim bum bam! come segnale che dà il via alla valutazione dell’ effort della User Story, oppure Un due tre! passando anche loro come scolaretti alle prese con un gioco durante la ricreazione.

La cerimonia Agile di cui sto parlando è il Sizing, o dimensionamento, serve a valutare lo sforzo/complessità di una User Story.

Una volta presentata la User Story i componenti del team chiedono al PO ulteriori dettagli e nella stessa occasione mostrano implicazioni e conoscenze del problema in modo da fornire un quadro il più possibile completo a tutti.

Quando la User Story è compresa da tutti i membri del team si procede alla votazione utilizzando un set di valori predefinito (molto usata e la sequenza di Fibonacci 1, 1, 2, 3, 5, 8, 13, 21, etc)

Tipicamente si predispone una board composta da tante colonne quanto sono i possibili valori della votazione. Per ogni colonna si dispone una User Story già lavorata dello stesso valore della colonna.

Si avranno cosi 6 colonne (ad esempio) la prima con il valore 1 e a seguire 2, 3, 5, 8 e 13.

Ogni colonna contiene una schedina con titolo e descrizione di una lavorazione di valore corrispondente prese dalla precedente iterazione.

Si procede alla “votazione” della User Story paragonandola a quelle già lavorate partendo da un estremo e spostandosi verso l’altro.

Ci si chiede “Questa lavorazione ha un effort pari o superiore alle user story contenute nella prima colonna?”; stessa cosa con la seconda colonna e così via fino a quando non vi è accordo sul suo effort.

Questa è il metodo di attribuzione del valore attraverso comparazione relativa**.

Quando ci sono le condizioni giuste però (come maggiore esperienza dei componenti del team, User Story che non sono correlate a lavorazioni precedenti – vedi Change Request e Bug Fixing) è possibile sparare direttamente il valore ritenuto corretto dallo sviluppatore in un gioco simile a quelli indicati a inizio articolo.

E siccome bisogna spararla non vi è nessun motivo di non farlo divertendosi!

**(non riporto qui i metodi di disambiguazione o mediazione del punteggio per non riempire il web di informazioni meglio scritte da altre parti)