Guida Scrum · Artefatti e pratiche
Backlog refinement in Scrum: come condurlo al meglio
Il backlog refinement è l'attività continua di scomporre gli elementi del Product Backlog e aggiungervi dettagli, come descrizione, ordine e dimensione. In Scrum non è un evento formale: mantiene la parte alta del Product Backlog abbastanza chiara da permettere al team di pianificare gli Sprint con fiducia.
Punti chiave
- Il backlog refinement è un'attività continua, non un evento Scrum formale.
- Scompone gli elementi e aggiunge dettagli come descrizione, ordine e dimensione.
- Product Owner e Developer fanno refinement insieme; i Developer dimensionano il lavoro.
- Mantenete pronti elementi per circa uno o due Sprint e suddivideteli verticalmente.
Che cosa è il refinement e che cosa non è
La Guida Scrum 2020 descrive il Product Backlog refinement come l'attività di scomporre e definire ulteriormente gli elementi in elementi più piccoli e precisi. È un'attività continua, quindi non è uno dei cinque Eventi Scrum. Molti team tengono comunque una sessione di refinement regolare perché rende il lavoro prevedibile.
| Il refinement è | Il refinement non è |
|---|---|
| Chiarire che cosa significa un elemento e perché è importante | Impegnarsi sul lavoro per lo Sprint successivo |
| Suddividere elementi grandi in elementi più piccoli | Assegnare attività alle singole persone |
| Dimensionare gli elementi in modo da poterli ordinare e fare previsioni | Progettazione tecnica dettagliata di ogni elemento |
| Aggiungere criteri di accettazione | Una riunione di avanzamento |
| Continuo e collaborativo | Qualcosa che il Product Owner fa da solo |
Chi partecipa
- Product Owner: fornisce il contesto, spiega il valore degli elementi e accetta i compromessi. È responsabile del backlog.
- Developer: pongono domande, suggeriscono suddivisioni e opzioni più semplici e dimensionano gli elementi. La Guida Scrum li rende responsabili del dimensionamento.
- Scrum Master: aiuta quando serve, ad esempio facendo coaching al team sulle tecniche di suddivisione o mantenendo le sessioni focalizzate.
- Stakeholder ed esperti: invitati quando un elemento richiede le loro conoscenze, come un cliente, un designer o uno specialista di compliance.
Quanto tempo dedicare
La Guida Scrum 2020 non fissa un limite di tempo per il refinement. Le versioni precedenti suggerivano che di solito non richiede più del 10% della capacità dei Developer, e molti team usano ancora questo valore come riferimento indicativo. In uno Sprint di due settimane, ciò corrisponde spesso a una o due sessioni di circa un'ora, più conversazioni informali.
Come condurre una sessione di refinement
- Preparate. Il Product Owner sceglie gli elementi in cima al backlog che richiedono attenzione e li condivide in anticipo.
- Spiegate il perché. Per ogni elemento, il Product Owner descrive il problema, l'utente e il risultato desiderato.
- Ponete domande e rispondete. I Developer esplorano casi limite, dipendenze e rischi. Annotate le domande aperte e chi risponderà.
- Concordate i criteri di accettazione. Annotate le condizioni che dimostreranno che l'elemento funziona.
- Suddividete se necessario. Se un elemento non può essere Done entro uno Sprint, suddividetelo in porzioni più sottili che forniscano comunque valore.
- Dimensionate. I Developer stimano, ad esempio con gli story point e il Planning Poker.
- Riordinate. Il Product Owner adegua l'ordine in base a quanto appreso.
- Chiudete. Confermate quali elementi sono pronti per lo Sprint Planning e quali azioni di follow-up servono.
Modi per suddividere elementi grandi
| Tecnica | Esempio |
|---|---|
| Per fase del workflow | "Checkout" diventa revisione del carrello, dati di consegna e pagamento |
| Per regola di business | Prima la consegna standard, poi la consegna express |
| Per tipo di dati o di input | Prima i pagamenti con carta, poi i portafogli digitali |
| Per utente o ruolo | Prima i clienti, poi gli amministratori |
| Prima la versione semplice, poi miglioramenti | Prima la ricerca di base, poi i filtri, poi le ricerche salvate |
| Prima uno spike | Un'indagine con time-box prima di stimare un elemento incerto |
Suddividete verticalmente, in modo che ogni porzione sia utilizzabile autonomamente, anziché orizzontalmente in livelli come database, interfaccia e test. Vedi epic vs story vs task.
Esempio svolto
Un team affina l'elemento "I clienti possono tracciare il proprio ordine", che secondo i Developer vale circa 20 punti: troppo per uno Sprint in cui di solito completano circa 25 punti insieme ad altro lavoro. Dopo una discussione lo suddividono:
| Nuovo elemento | Criteri di accettazione (sintesi) | Dimensione |
|---|---|---|
| Mostrare lo stato dell'ordine nella pagina dell'account | Lo stato mostra effettuato, imballato, spedito o consegnato | 5 |
| Email alla spedizione di un ordine | Email inviata entro 10 minuti, con link di tracciamento | 3 |
| Mostrare il tracciamento del corriere nella pagina dell'account | Tracciamento in tempo reale dall'API del corriere | 8 |
| Spike: limiti dell'API del corriere | Risposta: possiamo interrogarla ogni 15 minuti? | 2 |
Il totale è di 18 punti e ogni elemento è utilizzabile autonomamente. Il Product Owner mette per primi la pagina di stato e l'email, perché forniscono la maggior parte del valore, e subito dopo lo spike, così l'elemento di tracciamento è meno rischioso quando arriva in cima.
Consigli ed errori comuni
- Fate refinement in modo continuo, non solo di corsa il giorno prima dello Sprint Planning.
- Mantenete le sessioni brevi e focalizzate sulla parte alta del backlog.
- Coinvolgete l'intero team, o almeno i Developer che probabilmente svolgeranno il lavoro; il dimensionamento fatto da una sola persona fa perdere la comprensione condivisa.
- Non specificate troppo: lasciate spazio alla conversazione durante lo Sprint.
- Usate una checklist leggera, a volte chiamata Definition of Ready, se aiuta, ma non trasformatela in un cancello che blocca lavoro utile.
- Tenete traccia in modo visibile delle domande aperte, così da ottenere risposta prima dello Sprint Planning.
Modelli gratuiti per questo argomento
Domande frequenti
Che cos'è il backlog refinement in Scrum?
È l'attività continua di scomporre gli elementi del Product Backlog e aggiungervi dettagli, come descrizione, ordine e dimensione, in modo che siano pronti per lo Sprint Planning.
Il backlog refinement è un evento Scrum?
No. La Guida Scrum 2020 lo descrive come un'attività continua, non come uno dei cinque eventi. I team possono comunque programmare sessioni di refinement regolari.
Backlog refinement e backlog grooming sono la stessa cosa?
Sì. Grooming è il termine più vecchio; refinement lo ha sostituito nella Guida Scrum ed è ora il nome standard.
Chi partecipa al backlog refinement?
Il Product Owner e i Developer, con l'aiuto dello Scrum Master quando utile. Stakeholder o esperti partecipano quando un elemento richiede il loro contributo.
Quanto tempo dovrebbe richiedere il backlog refinement?
La Guida Scrum 2020 non fissa limiti. Le versioni precedenti suggerivano di non superare circa il 10% della capacità dei Developer, che rimane un riferimento comune.
Con quale frequenza dovremmo fare refinement del backlog?
In modo continuo. Molti team tengono una o due brevi sessioni per Sprint e gestiscono le domande minori man mano che emergono.
Chi effettua le stime durante il backlog refinement?
I Developer che svolgeranno il lavoro. Il Product Owner spiega gli elementi e i compromessi, ma non stabilisce le stime.
Qual è la differenza tra backlog refinement e Sprint Planning?
Il refinement prepara gli elementi nel tempo. Lo Sprint Planning è un evento con time-box in cui il team definisce lo Sprint Goal, seleziona gli elementi e pianifica il lavoro.
Che cosa significa pronto nel backlog refinement?
La Guida Scrum afferma che gli elementi che possono essere Done entro uno Sprint sono considerati pronti per essere selezionati nello Sprint Planning. Alcuni team aggiungono una Definition of Ready facoltativa.
Con quanto anticipo dovremmo fare refinement del backlog?
Di solito per quanto basta per i prossimi uno o due Sprint. Fare refinement troppo in anticipo rischia di generare sprechi, perché priorità e comprensione cambiano.
Il backlog refinement può avvenire durante lo Sprint?
Sì. Avviene per tutta la durata dello Sprint, in parallelo al lavoro sullo Sprint Backlog corrente.
Che cosa fare se le sessioni di backlog refinement sforano continuamente?
Preparate gli elementi in anticipo, concentratevi sulla parte alta del backlog, assegnate un time-box a ogni elemento e spostate le questioni tecniche approfondite in un follow-up più ristretto o in uno spike.