Sul muro della stanza del team c’è un grafico molto semplice, riporta i giorni di uno sprint sull’asse delle ascisse e gli story point sull’asse delle ordinate. Il grafico si chiama sprint burndown chart: ogni volta che si chiudono una o più storie in un dato giorno dello sprint, la somma degli story point viene sottratta alla totalità iniziale. Non mi dilungo a spiegare i concetti di sprint e story point, li do per scontato altrimenti finirei per dare una struttura frattale e potenzialmente illimitata a questo post.
Alla fine del planning lo scrum master traccia una linea retta dal giorno 0 e story point totali previsti per quello sprint fino all’ultimo giorno a story point 0; questa è la linea ideale di rilascio lineare di story points dall’inizio alla fine. Quindi, alla fine di ogni giornata, segna invece gli story point delle storie messe quel giorno in stato done, o meglio to be reviewed; la linea che unisce questi punti è l’andamento reale dello sprint, chiamato sprint burndown chart.
Ed ecco la rivelazione. Quanto più la linea è aderente o quanto meno parallela alla linea ideale, tanto più la totalità delle pratiche metodologiche prescritte dallo scrum saraà stata eseguita con successo. In altre parole, la linea reale è vicina all’andamento teorico se le user stories sono piccole e cross funzionali (cioè tagliate in modo da poter essere lavorate con poco tempo da più membri del team), il team è concentrato sul lavoro e meno distratto da pratiche non funzionali al raggiungimento del goal dello sprint corrente (compresa l’attività di grooming per lo sprint successivo), la definition of ready delle user stories è stata valutata con attenzione, le user stories sono state realisticamente valutate, il tester è abilitato a lanciare i suoi test etc.; tutto questo influisce sulla capacità del team di chiudere user stories in maniera uniforme e continuativa, senza eccessivi accumuli di work in progress.
Ecco una sprint burndown chart. Rappresenta l’andamento di uno sprint fantastico, in cui tutto è andato come i migliori manuali di scrum prevedono. La linea rossa rappresenta l’andamento teorico, quella verde l’andamento reale del rilascio di story point. Sin dal primo giorno il team si è portato in vantaggio con il lavoro chiudendo la prima storia il secondo giorno, probabilmente perché il lavoro di planning e divisione in task previsto per il primo lunedì era stato abbastanza veloce da consentire al team di lavorare e chiudere una storia.
Nei giorni successivi altri story points sono stati macinati con una certa continuità, a parte un moderato rallentamento nei primi giorni della seconda settimana, avendo preso in carico storie più complesse.
Anche questa è una bella burndown chart, anzi forse addirittura più bella della precedente. Dopo il primo giorno di planning e il secondo di lavoro il team ha iniziato a rilasciare parti di codice completi e pronti per la revisione con una continuità assoluta, per cui la curva verde si presenta del tutto parallela alla linea ideale. Con poco sforzo finale il team ha concluso lo sprint con il rilascio di tutti gli story point stimati.
Ecco una burndown chart brutta. Forse il team ha aperto storie in contemporanea per 20 story points, o forse le attività di test sono rimaste bloccate per troppo tempo. Di certo, Giovedì 10 Maggio è stata una brutta giornata per il team