Ottimizzazione del backlog (grooming): cadenza, responsabilità e significato del termine “pronto”
L’affinamento del backlog — ancora denominato “grooming” — consiste nel lavoro continuo volto a preparare gli elementi prima dello sprint in cui verranno realizzati: chiarimento, valutazione della portata, suddivisione e ordinamento.
L’affinamento del backlog — ancora comunemente denominato “grooming” — è il lavoro continuo volto a preparare gli elementi del backlog di prodotto prima dello sprint in cui verranno realizzati: chiarire il significato di ciascun elemento, suddividere quelli troppo grandi, aggiungere criteri di accettazione, valutarne la portata e mantenerli ordinati per priorità. Non si tratta tanto di una singola riunione quanto piuttosto di un’abitudine. Ed è proprio questa sottile differenza che distingue una pianificazione dello sprint serena da una pianificazione dello sprint che si trasforma in una discussione di due ore.
Si tratta di una cerimonia o no?
Tecnicamente, no. La Guida allo Scrum non indica l’affinamento del backlog come uno degli eventi, ma lo descrive come un’attività continua che non dovrebbe richiedere più del 10% circa della capacità degli sviluppatori. Pertanto, i puristi hanno ragione: non si tratta di una cerimonia.
Eppure la guida di Asana alle cerimonie agili è intitolata “4 eventi + affinamento del backlog”, e la maggior parte dei team operativi dedica all’affinamento una sessione fissa in calendario, gestendola come qualsiasi altra cerimonia. Entrambe le posizioni indicano la stessa verità da prospettive diverse: l’affinamento non è un evento formale, ma trattarlo come tale è solitamente la scelta giusta. Se lo si tralascia, il costo non scompare: si sposta semplicemente nella pianificazione dello sprint, dove risulta più oneroso e in un momento meno opportuno.
In cosa consiste effettivamente la raffinatezza
Il processo di perfezionamento prende le voci grezze del backlog — spesso un titolo e una vaga speranza — e le rende gestibili. In pratica si tratta di quattro fasi, che si susseguono senza interruzioni:
- Chiarire. Trasformare l’espressione “migliorare l’onboarding” in un obiettivo con un intento chiaro e criteri di accettazione che il team possa verificare.
- Suddivisione. Suddividete gli elementi troppo grandi per essere completati in un unico sprint in parti più piccole, ciascuna delle quali abbia un valore intrinseco. Si tratta di un’arte a sé stante — consultate la suddivisione delle user story.
- Dimensioni. Concordare una stima in story point, solitamente tramite il planning poker, in modo che lo sforzo relativo sia chiaro prima di assumersi l’impegno.
- Ordine. Mantenete il backlog ordinato in modo che i lavori più importanti e più pronti si trovino in cima, dove la pianificazione possa individuarli facilmente.
Il risultato non è un documento. Si tratta di un buffer dinamico di elementi pronti per essere prelevati — in genere con uno o due sprint di anticipo rispetto alla posizione attuale del team.
Frequenza: con quale frequenza, per quanto tempo
Non esiste una regola fissa, ma vi è un approccio predefinito ragionevole: una breve sessione ricorrente come punto di riferimento, oltre a piccoli interventi continui nel frattempo.
Per uno sprint di due settimane, la maggior parte dei team organizza un’unica sessione di affinamento a metà sprint, della durata prestabilita di circa un’ora, integrandola in modo ad hoc man mano che sorgono domande. Anche una frequenza settimanale funziona altrettanto bene. Ciò che conta non è tanto la fascia oraria esatta quanto il margine di sicurezza: l’obiettivo è quello di avere sempre in coda una quantità di lavoro pronto pari all’incirca alla durata di uno sprint, in modo che durante la pianificazione non si debba mai aprire il backlog per poi non trovare nulla a cui dedicarsi.
Due modalità di fallimento definiscono il giusto equilibrio. Se la quantità è insufficiente, la pianificazione si trasforma in un processo di perfezionamento sotto pressione: il team chiarisce e suddivide i compiti contro il tempo, impegnandosi in un lavoro che comprende a malapena. Se invece è eccessiva, il perfezionamento si trasforma in una seconda riunione di pianificazione, in cui si discute minuziosamente di dettagli relativi a elementi che potrebbero non arrivare mai a uno sprint. Se si rimane entro i limiti indicati dalla Guida Scrum (~10% della capacità), la pianificazione rimane utile.
Chi lo gestisce
Il Product Owner è responsabile del backlog: la priorità, l’intento e il perché di ogni elemento sono di sua competenza. Tuttavia, il processo di affinamento è un lavoro di squadra. Sono gli sviluppatori a porre le domande scomode, a far emergere le complessità che nessuno aveva previsto e a occuparsi della valutazione effettiva delle dimensioni. Un Product Owner che effettua il perfezionamento da solo produce elementi che risultano chiarissimi solo per una persona e pieni di sorprese per tutti gli altri nel momento in cui ha inizio la pianificazione.
Lo Scrum Master garantisce il rispetto dei tempi previsti per la sessione ed evita che questa degeneri in una fase di progettazione collettiva. Oltre a ciò, meno spettatori ci sono, meglio è.
Cosa significa “pronto”: la definizione di “pronto”
Lo scopo del processo di perfezionamento è rendere gli elementi pronti — e il termine “pronto” merita una definizione, proprio come “completato”. Una Definizione di “pronto” semplificata consiste nella lista di controllo che un elemento deve soddisfare affinché il team lo includa nella pianificazione: è ben compreso, è sufficientemente piccolo da poter essere completato in uno sprint, dispone di criteri di accettazione, le dipendenze sono note ed è stato stimato.
Il perfezionamento e la pianificazione sono una staffetta, non una rivalità: il perfezionamento prepara gli elementi, la pianificazione li conferma. Se nel vostro team il confine tra i due vi sembra sfocato, pianificazione dello sprint vs perfezionamento del backlog lo delinea chiaramente. Per quanto riguarda la posizione del perfezionamento rispetto agli eventi formali, si veda eventi Scrum vs cerimonie.
Domande frequenti
Che cos’è l’affinamento del backlog?
L’attività continua volta a preparare gli elementi del product backlog affinché possano essere sviluppati: chiarire il significato di ciascun elemento, suddividere quelli più grandi, aggiungere criteri di accettazione, valutarne la portata e riordinarli in base alla priorità. Tale attività si svolge in modo continuativo durante lo sprint, in modo che, quando un elemento raggiunge la fase di pianificazione, il team possa impegnarsi a realizzarlo senza difficoltà.
L’affinamento del backlog è una cerimonia Scrum?
No — la Guida allo Scrum non la indica come un evento. Si tratta di un’attività continuativa, non di una riunione fissa, e la Guida allo Scrum precisa che non dovrebbe richiedere più del 10% circa della capacità degli sviluppatori. Tuttavia, la maggior parte dei team le dedica una sessione ricorrente e la tratta come una cerimonia, poiché saltarla è ciò che trasforma la pianificazione dello sprint in un caos.
Qual è la differenza tra la “backlog grooming” e il “backlog refinement”?
Nessuna — si tratta della stessa attività. “Grooming” è il termine originario; la comunità Scrum è passata a “refinement” perché “grooming” aveva assunto connotazioni negative. Molti team continuano a utilizzare il termine “grooming”. Il lavoro è identico in entrambi i casi.
Con quale frequenza è opportuno aggiornare il backlog?
In modo continuativo, con una breve sessione ricorrente come punto di riferimento — solitamente una volta alla settimana, oppure una volta a metà sprint nel caso di una cadenza di due settimane, della durata prestabilita di circa un’ora. L’obiettivo è quello di mantenere una riserva continua di elementi pronti, solitamente con uno o due sprint di anticipo, in modo che la pianificazione disponga sempre di materiale valido da cui attingere.
Chi si occupa della definizione del backlog?
Il Product Owner è responsabile del backlog e ne definisce le priorità e gli obiettivi, ma il processo di affinamento è un’attività di squadra: sono gli sviluppatori a porre le domande, a portare alla luce le complessità nascoste e a stimare l’entità del lavoro. Un Product Owner che affina il backlog da solo produce elementi che hanno senso solo per lui e che sorprendono tutti gli altri durante la fase di pianificazione.