Gli story point spiegati bene
Se chiedi a un team «quanto ci vuole?», ricevi ore, giornate e molte discussioni. Se chiedi «è più grande o più piccola di quella che abbiamo fatto il mese scorso?», la risposta arriva prima e il team si trova d’accordo più spesso. Gli story point nascono da questa seconda domanda. Sono un’unità relativa: un 8 vuol dire «parecchio più grande di un 5», e non dice niente su quante ore serviranno. Nei team Scrum e XP sono diventati l’unità più comune per la stima agile.
Cosa misura uno story point
In un solo numero finiscono tre cose diverse.
La prima è la quantità di lavoro. Un modulo di iscrizione alla mensa scolastica con venti campi e le sue regole richiede più tempo di una pagina con un solo campo di ricerca.
La seconda è la complessità, cioè quanto è difficile fare le cose per bene. Il calcolo della tariffa della mensa in base all’ISEE può stare in poche righe di codice e richiedere comunque mezza mattina di ragionamento sugli scaglioni.
La terza è l’incertezza, cioè quanto ancora non si sa. Il dato ISEE lo fornisce l’INPS, di solito attraverso la PDND, la piattaforma nazionale per lo scambio di dati tra enti. Se il comune non ci si è mai collegato, bisogna chiedere l’accesso, capire i tempi e provare il servizio in collaudo. Nessuno nel team sa quanto ci vorrà, e la storia prende un numero più alto anche se il codice da scrivere è poco.
Le tre voci non si sommano con una formula. Ognuno le combina a modo suo e gioca una sola carta, che non dice quale delle tre ha pesato di più. Per questo un 8 nel backlog racconta meno di quanto sembri, e spesso una riga di commento sul ticket («8 soprattutto per l’accesso alla PDND») vale quanto il numero. Nel planning poker le ragioni vengono fuori da sole quando i voti divergono; quando coincidono, annotarle costa poco.
Perché non stimare in ore
Un preventivo in giornate è una richiesta legittima. Il problema nasce quando le ore diventano l’unità di ogni singola storia.
Per stimare in ore bisogna sapere chi farà il lavoro, perché la stessa modifica richiede tempi molto diversi a persone diverse. In un team Scrum, però, chi prende una storia si decide durante lo sprint, spesso la mattina stessa. Stimare in ore costringe ad assegnare il lavoro in anticipo, oppure a inventare uno «sviluppatore medio» che nel team non esiste. Un punto descrive il lavoro, e il team può mettersi d’accordo senza sapere chi lo farà.
Le ore misurano l’impegno, non il calendario. Una storia da tre giorni di lavoro può restare aperta due settimane, se deve aspettare l’accesso alla PDND o la risposta di un altro ufficio. Con i punti quell’attesa non va stimata a parte: se nello sprint scorso le approvazioni esterne hanno frenato tutto, la velocity è scesa e il piano successivo ne tiene conto senza che nessuno debba fare conti.
C’è poi il margine di sicurezza. Chi stima in ore sa che quel numero gli verrà ricordato, e ci aggiunge qualcosa per prudenza, ognuno a modo suo e senza dirlo. Sommando le stime si sommano anche i margini nascosti, e nessuno sa più quanto lavoro c’è davvero. Con i punti il margine non ha dove nascondersi: se una storia viene votata 8, deve reggere il confronto con le storie di riferimento davanti a tutto il team.
Scegliere una storia di riferimento
Per stimare in modo relativo servono uno o due punti fissi: storie chiuse da poco, che quasi tutti ricordano, senza grosse sorprese e sulla parte del sistema che il team tocca più spesso.
Un team che sviluppa servizi di pagamento per i comuni, per esempio, parte da una storia sola: «inviare una email di conferma quando il pagamento pagoPA va a buon fine». Le dà 3 e non 1, così sotto resta spazio per i lavori ancora più piccoli. Dopo qualche sprint si accorge che per le storie grosse quel termine di paragone è troppo piccolo: confrontare una migrazione con una email è come misurare un corridoio con il righello. Aggiunge allora una seconda storia di riferimento più grande, l’export in CSV dei movimenti filtrabile per data e causale, che nel frattempo tutti ricordano come un 8.
Scrivile da qualche parte, nella pagina del team sul wiki o nel README del progetto, con due righe su perché valgono quel numero.
La velocity
La velocity è la somma dei punti delle storie completate in uno sprint, dove «completate» vuol dire che rispettano la definizione di fatto. Una storia ferma in code review l’ultimo giorno non porta punti, nemmeno una parte: li porterà nello sprint in cui viene chiusa.
Prendi gli ultimi quattro sprint di un team: 31, 26, 34 e 29 punti. Si pianifica con la fascia tra 26 e 34, non con un singolo valore. Il team sa che prendere 30 punti nello sprint successivo è ragionevole e che 40 è una scommessa. Il product owner, con 180 punti ancora da fare sulla release, può fare un conto semplice ai due estremi: 180 diviso 34 fa poco più di 5, 180 diviso 26 fa quasi 7. Al cliente conviene dire «tra sei e sette sprint», e aggiornare la previsione strada facendo.
Perché la fascia resti stretta servono un po’ di condizioni: le stesse persone, un tipo di lavoro simile da uno sprint all’altro, poche urgenze che arrivano a sprint iniziato. Quando il team perde due sviluppatori o passa metà sprint a spegnere incendi in produzione, la velocity di quel periodo non va usata per le previsioni. Come la velocity entra nel refinement e nello Sprint Planning lo trovi nella pagina sullo scrum poker.
Miti che creano problemi
«Un punto vale mezza giornata»
Prima o poi qualcuno chiede la tabella di conversione, di solito per un preventivo. Appena esiste, il team comincia a stimare in mezze giornate e a scrivere il risultato in punti. Si perde tutto quello che rendeva utili i punti e si tiene solo la fatica. A chi chiede una data si risponde con la velocity: «con il ritmo attuale, tra sei e sette sprint».
«Possiamo confrontare i team con la velocity»
Immagina una direzione che ogni mese mette in un foglio Excel la velocity di tutti i team e la presenta in riunione. Il team dell’app risulta a 45, quello del backoffice a 18. I due numeri non sono confrontabili: il team dell’app ha fissato il suo 2 su una schermata con un form, il backoffice su un job notturno di riconciliazione, e da lì in poi ognuno ha costruito la propria scala. Il confronto però produce un effetto. Alla prima revisione delle storie di riferimento il backoffice ne sceglie una un po’ più «generosa», i numeri salgono e nel foglio il divario si riduce. Nessuno ha lavorato di più, e il team ha perso gli ultimi sei mesi di velocity confrontabile.
«Se la stima era sbagliata, qualcuno ha sbagliato»
Una stima è un’ipotesi fatta con le informazioni di quel giorno. Quando una storia da 3 si rivela da 13, di solito è emerso qualcosa che prima nessuno sapeva. Cercare il colpevole insegna a votare alto per prudenza; chiedersi cosa mancava insegna a fare domande migliori.
Come cominciare
Il primo incontro può essere diverso da una normale sessione di stima. Prendi otto o dieci storie già chiuse negli ultimi mesi, scrivi i titoli su foglietti o su una lavagna online e chiedi al team di mettere le storie in fila, dalla più piccola alla più grande. Poi assegnate insieme i numeri del mazzo standard, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100: la più piccola ragionevole diventa 1 o 2 e le altre si distribuiscono di conseguenza. Perché il mazzo abbia quegli intervalli è spiegato nella pagina sulla sequenza di Fibonacci. Da quella fila scegli una o due storie di riferimento.
Dal refinement successivo si passa alle storie nuove, con il planning poker e una stanza online gratuita senza registrazione. Conviene stimare solo quello che sta in cima al backlog, già ordinato dal product owner: le storie più lontane cambieranno prima di arrivare in uno sprint.
Prima di usare la velocity per promettere date al cliente aspetta di avere quattro o cinque sprint alle spalle. Nel frattempo guarda quali storie sforano di più: se sono sempre quelle che toccano lo stesso sistema esterno, il problema è l’incertezza su quel sistema, e un’indagine breve prima del voto aiuta più di qualunque correzione della scala.