Lo Sprint Backlog in Scrum

Lo Sprint Backlog in Scrum funziona in maniera analoga al Product Backlog. È il risultato dello Sprint Planning e comprende un elenco ordinato di attività che il team seleziona e che si impegna di portare a termine entro la fine dell’iterazione, detta Sprint.

Chi fa cosa

Non è compito del Product Owner selezionare i task da aggiungere allo Sprint Backlog, ma un’attività che il team di sviluppo compie in maniera collaborativa durante la pianificazione dello Sprint.

Tuttavia il Product Owner ha la facoltà e il potere di decidere il sottoinsieme che il team deve prendere in considerazione, solitamente rendendo espliciti gli obiettivi e priorizzando in maniera efficace il Product Backlog.

Una volta che il team ha valutato l’effort di ciascuna user story, solitamente durante il Refinement Meeting (detto anche Grooming), può procedere con la suddivisione in task durante lo Sprint Planning – ed eventualmente la stima in ore di ciascun task, se necessario o richiesto. Parleremo presto dei meeting che compongono Scrum.

Com’è fatto lo Sprint Backlog

All’interno dello Sprint Backlog sono presenti diverse informazioni come:

  • Elenco delle user story che fanno parte dello Sprint
  • Stima dell effort per ciascuna user story – in Story Point
  • Elenco dei task per ciascuna user story
  • Stima in ore per ciascun task
  • Acceptance criteria
  • Link a risorse esterne

Può anche includere:

  • Nome della persona che ha in carico il task
  • Grafici
  • Sprint Goal – l’obiettivo da raggiungere entro il termine dello Sprint

Le user story sono inserite nello Sprint Backlog in ordine di priorità, le più importanti prima e le meno importanti dopo. A differenza del Product Backlog, dove le stime sono in Story Point, nello Sprint Backlog le stime di ciascun task sono espresse in ore di sviluppo. Se un task è più grande di una giornata di lavoro è un buon motivo per dividerlo in più task più piccoli.

Ti suggerisco di includere lo Sprint Goal da qualche parte, in modo che il team non lo perda di vista!

sprint backlog
By agileway.it – Creative Commons. Clicca per ingrandire.

Nella tabella qui sopra ti riporto un esempio di Sprint Backlog su foglio di calcolo (clicca per ingrandire). Per il tuo Sprint Backlog utilizza tool open source che trovi su Internet o qualsiasi strumento ritieni adeguato. Considera che deve poter essere aggiornato da più persone, è infatti responsabilità di ciascuno sviluppatore tenere aggiornato il conto delle ore.

IEH e pianificazione

La sigla IEH è l’acronimo di Ideal Engineering Hours, che tradotto in italiano significa “ore di sviluppo ideali”. Una giornata lavorativa è di solito composta da 8 ore, ma è anche vero che non tutte e otto le ore vengono utilizzate per sviluppare. Molto tempo se ne va in riunioni, oppure per leggere le mail, o per parlare al telefono.

Quando si effettua la pianificazione durante lo Sprint Planning, è buona norma considerare 6 ore di sviluppo ideali (Ideal Engineering Hours) al giorno, lasciando quindi uno spazio di due ore per tutte le altre attività.

La matematica per capire quante ore di sviluppo si hanno a disposizione per ciascuno Sprint è quindi molto semplice. Le IEH vengono moltiplicate per i giorni di lavoro che costituiscono lo Sprint e per ciascuno sviluppatore allocato nell’iterazione. Nel caso di uno Sprint di due settimane i giorni lavorativi sono 10, e in caso di un team composto da 4 sviluppatori – il Product Owner e lo Scrum Master in genere non sono sviluppatori e non vengono conteggiati – si ha un totale di 240 ore.

Ore sviluppo = Giorni Sprint x IEH x Numero sviluppatori

La pianificazione dello Sprint è il momento ideale per discutere eventuali ferie o assenze dall’ufficio, fatta eccezione per i periodi di malattia che, si spera, non vengono pianificati e sono imprevedibili.

Perché aggiungere un po’ di buffer

I task aggiunti allo Sprint Backlog e le relative stime possono essere rivisti e modificati dal team durante lo svolgimento dello Sprint: può succedere che in fase di pianificazione alcuni aspetti siano stati dimenticati o alcune previsioni siano totalmente sballate. Per metterti al riparo da problemi, ti consiglio di aggiungere un 20% di buffer.

Se hai 240 ore di sviluppo a disposizione pianifica al massimo per 192. Il buffer non solo ti mette al riparo da una pianificazione imprecisa, ma ti dà la possibilità di riservare del tempo per la correzione di bug urgenti che potrebbero essere riportati dal cliente sull’ambiente di produzione. Se avanza tempo c’è sempre la possibilità di consultare il Product Owner e aggiungere altre attività!

Perché i task sono importanti

Suddividere le user story in task ti aiuta a ricordare tutte le fasi che devi implementare, dà visibilità su ciò che è stato fatto e su ciò che rimane da fare, e consente a più persone di lavorare sulla stessa user story.

Grazie ai task è possibile creare grafici che aiutano il team ad avere un colpo d’occhio sui progressi e su quanto rimane da fare entro il termine dello Sprint.

Oltre al punto di vista pratico, completare un task fa sentire più “in controllo” e aumenta l’autostima. Se sei un procrastinatore ti consiglio vivamente di far uso di tanti task molto piccoli, in modo da completarne il più possibile, mettere in moto una spirale positiva e aumentare la tua produttività.

Detto ciò, ci tengo a precisare che la suddivisione in task, così come l’approccio IEH, sono opzionali e non sono prescritti da Scrum. Sono indubbiamente un ottimo metodo da utilizzare, a patto però che i Developer lo ritengono utile e non un ostacolo alla propria pianificazione.

Immagine in copertina rilasciata sotto Creative Commons da Vic su Flickr.

È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!

videocorso agile way su scrum e sulle metodologie agili

CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI

Aggiornato all’ultima versione della guida ufficiale di Scrum!

Più di 3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:

  • Origine, nascita e significato delle metodologie Agili
  • Differenze tra Scrum e i modelli tradizionali
  • Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
  • Come gestire al meglio un progetto e un prodotto con Scrum
  • Come mantenere un’attenzione continua al valore generato e al cliente
  • Simulatore di esame di certificazione (80 domande)
  • Tanto altro…

* Offerta limitata nel tempo

Subscribe
Notificami
guest
2 Commenti
più vecchi
più nuovi più votati
Inline Feedbacks
View all comments
Marcello Kad Cadoni
Marcello Kad Cadoni
6 anni fa

Un organizzazione simile crea solo confusione, perché chi si trova a dover aggiornare le ore, sopratutto se sta realizzando storie condivise da piu componenti del team di sviluppo, non ha idea di cosa aggiornare e cosa è stato aggiornato. Si risolve creando una colonna “nome sviluppatore” e duplicando le righe dei task (qualora condivisi) per il numero dei partecipanti allo sviluppo dello stesso.
In questo modo si ottiene un dettaglio maggiore del monitoraggio, un sistema meno “error-prone”, ed evidenzia il quantitativo di tempo utilizzato dal singolo componente del gruppo

Agile Way
Reply to  Marcello Kad Cadoni
6 anni fa

Se ti riferisci all’immagine di esempio riportata nell’articolo, sono d’accordo. Si può aggiungere una colonna “nome sviluppatore” per evitare confusione quando si aggiornano le ore.