#Step2: Come fare una stima del tuo Backlog di Progetto

Proseguiamo col secondo appuntamento della nostra Guida a Scrum in 10 facili step, argomento del giorno stima del Backlog di Progetto, la traduzione completa della guida offerta da Kelly Waters, che probabilmente conoscerete già se vi state affacciando al mondo agile.

Nel primo step abbiamo definito il Product Owner e steso il nostro backlog di progetto: è giunto il momento di fare una seria stima di quest’ultimo. Vediamo quindi come ce lo spiega Kelly.

Stima del Backlog di Progetto. Parti da una stima indicativa

Hai steso il tuo backlog e hai una lista di features che il tuo prodotto dovrà avere, ma non hai ancora, in questa fase, un’idea veramente precisa di come le implementerai e di tutti i task necessari per completare ogni feature. Non hai ancora un’idea chiara per effettuare una stima del backlog di progetto.

Quello che ti suggerisco di fare è di dare una stima di “alto livello”, una row per intenderci, che in questo momento ti sarà utile anche per farti un’idea più precisa di:

– gli elementi del backlog: quanti di quelli inseriti sono davvero essenziali, quanti tutto sommato potrebbero non valer la pena implementare.

– la composizione del team: ovvero – budget permettendo – la stima ideale di quante persone ti servirebbero e con quali competenze.

In realtà il team è definito a priori, sono però valutate chiaramente estensioni o consulenze esterne.

– l’ordine di grandezza del progetto nel suo complesso, in termini di tempi e costi.

Certo, so cosa stai pensando.
Quando ti dicono “Non mi aspetto una cifra dettagliata, mi basta qualcosa d’indicativo” non devi credergli alla lettera: ovvio che la vogliono, la cifra dettagliata. Calma, ora ci arriviamo ;).

Fai una stima per punti, non per tempo.

Il mio consiglio, aspetta a guardarmi con quegli occhi, è di non stimare gli elementi del backlog in termini di tempo, ma in termini di grandezza.
Lo so, ti sembra assurdo e rischioso: ma per ora dammi fiducia su questo e seguimi nel ragionamento, il perché si chiarirà più avanti.

La domanda che suggerisco di porsi di fronte ad ogni feature del prodotto non è: “Quanto tempo mi cuba quest’attività” bensì – attenzione – “Quanto grande è quest’attività”.
Ok. A questo punto vi domanderete: va bene, ci fidiamo, facciamo come dici tu.
Ma sulla base di quale scala attribuiamo un valore ad ogni elemento del backlog?
Io personalmente trovo molto comoda la sequenza di Fibonacci: potete leggere su Wikipedia in cosa consiste esattamente oppure – se siete pigri o semplicemente pragmatici- vi dico io i primi numeri della successione.
Sono:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 …

Di solito io mi limito ad usare i numeri entro il 21, lasciando il valore 610 ai casi in cui benga richiesto di andare sulla luna (andata e ritorno ) nel tempo di uno spot pubblicitario ;).

La chiave qui non è la grandezza in sé, ma la relatività: facciamo degli esempi concreti.

Un punto di backlog potrebbe essere la redazione di un report delle attività: cosa che già hai fatto per altri progetti, ma in questo caso esistono delle incognite, quindi vuoi tenerti più largo e gli attribuisci valore 3.
Se più avanti nel backlog ho un altro report da redarre, lo stimerò sulla base del precedente: 2 se ritengo sarà un po’ più semplice, 13 se valuto che sarà per qualche ragione decisamente più complesso.
Un buon punto di partenza in generale può essere questo:

• Estrai dal tuo backlog l’elemento che ti sembra più semplice e attribuiscigli valore 1.
• Poi quello in assoluto più complesso e dagli valore 21.
• Tara quindi gli elementi rimanenti con i relativi valori intermedi.

Fai la stima col tuo team, non da solo

Considera i vantaggi di fare quest’operazione in gruppo: due teste sono meglio di una, dice il proverbio, e non a caso. Qualcuno potrebbe tirar fuori criticità/rischi che non avevi notato. Qualcuno potrebbe offrire una soluzione semplice e fruttifera ad un interrogativo irrisolto.

Procedete punto per punto lungo la lista del backlog e confrontatevi insieme: ognuno fa la sua stima e la giustifica. Se emergono grosse differenze saranno frutto di discussione e nella maggior parte dei casi avranno esito in uno dei punti prima citati (si delineeranno criticità o al contrario si risolveranno).

Alcuni team usano l’approccio del pocker: per ogni feature di backlog ognuno “butta sul tavolo” la propria stima, e contemporaneamente può vedere quella fatta dagli altri. Non sottovalutate il potere umano e comunicativo di questo momento solo apparentemente “ludico”: perché sapete cosa succede? In questo modo state dando ad ognuno la possibilità di dire la sua, e sullo stesso piano. Nel contempo, state impedendo che le opinioni s’influenzino a vicenda, ed evitate che le personalità più forti in qualche modo schiaccino quelle più timide.

Eventualmente, rivedi l’ordine di priorità

Bene.
Avete attribuito un valore ad ogni elemento del backlog e può succedere questo:

• Il valore attribuito corrisponde tutto sommato alla “priorità” che gli avevate dato nella lista di backlog. Bravi. A naso ci avevate visto giusto.
• Il valore attribuito in fase di stima sembra in contrasto con la priorità all’interno della lista di backlog: questo è il momento di valutare un eventuale cambio di priorità e ordine. Un task si è rivelato – in sede di stima – abbastanza critico da ricevere un 21? Allora forse è meglio se lo porto più in alto nella lista di backlog.
  Un altro si è rivelato di semplice esecuzione? Posso anche valutare di farlo slittare alla release successiva.

Testa questo metodo, prima di modificarlo.

La tentazione di adattare i metodi alle nostre particolari esigenze è sempre forte: il mio consiglio è di non farlo, in questa fase iniziale in cui stai ancora approcciando Scrum per la prima volta.
Usatelo per qualche tempo, testatelo per così dire alla lettera, eventualmente su più progetti.

Solo quando lo avrete in qualche modo “automatizzato” e fatto vostro, allora potete pensare di modificarlo a vostra specifica esigenza.

Step #1: Tieni in ordine il tuo Backlog di progetto

Step #3: Come pianificare lo Sprint – I requisiti
Step #4: Come pianificare lo Sprint – I task
Step #5: Come creare un ambiente di lavoro collaborativo
Step #6: Come implementare lo Sprint con Scrum
Step #7: Standup e… fai sentire la tua voce!
Step #8: Traccia i progressi con un diagramma quotidiano
Step #9: Consegna in tempo!
Step #10: Rivedi, rifletti, ripeti.