Lo Sprint Backlog in Scrum

Lo Sprint Backlog in Scrum funziona in maniera analoga al Product Backlog. È un elenco ordinato di attività che il team seleziona e che si impegna di portare a termine entro la fine dell’iterazione, detta Sprint. 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.

Ovviamente 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 durante il Refinement Meeting (detto anche Grooming), può procedere con la suddivisione in task – e relativa stima in ore – durante lo Sprint Planning. 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!

By agileway.it - Creative Commons. Clicca per ingrandire.

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 un buffer 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.

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 mettersi 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à.

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