Tutto quello che devi sapere sul Product Backlog Refinement

Affinché uno Sprint possa essere pianificato e il lavoro possa iniziare in Scrum, il Product Backlog deve essere ben mantenuto e riempito con elementi del Product Backlog adeguatamente preparati. È logico che il Backlog debba essere raffinato regolarmente – ma come funziona esattamente?

In questo articolo ti mostreremo esattamente cosa significa il Product Backlog Refinement, a cosa dovresti prestare attenzione e perché il Refinement è così importante.

Cos’è il Product Backlog Grooming o Refinement in Scrum?

Fino a poco tempo fa, il Product Backlog Refinement in Scrum veniva chiamato Backlog Grooming. Il Backlog Refinement consiste nel mantenere e preparare il Product Backlog con i suoi elementi ed epic affinché lo Scrum Team possa utilizzarlo come base per lo Sprint Planning.

Product Backlog Refinement significa quindi: i Product Backlog Item vengono elaborati, valutati e prioritizzati in modo tale che il Development Team possa compilare da essi il proprio Sprint Backlog. Un Product Backlog ben mantenuto dovrebbe sempre contenere almeno un numero sufficiente di Product Backlog Item preparati per pianificare uno Sprint completo.

L’obiettivo generale del Backlog Grooming è assicurare che il Development Team comprenda la visione di prodotto del Product Owner e le User Story da lui create, e sia quindi in grado di pianificare il prossimo Sprint secondo gli Sprint Goal.

A proposito, se cerchi il termine Refinement nella Scrum Guide, scoprirai che non è uno degli eventi o occorrenze ufficiali di Scrum come Sprint e Daily Scrum. Piuttosto, il Product Backlog Refinement è una cosiddetta attività che si svolge come meeting. Oltre al Product Owner e al Development Team, al meeting di Refinement partecipano lo Scrum Master e – soprattutto nel caso di Refinement strategici – gli stakeholder.

Ecco come funziona il Backlog Refinement Meeting

Prima del vero e proprio Backlog Refinement c’è la preparazione:

• Il Product Owner stabilisce l’obiettivo dello Sprint (Outcome).
• Secondo questo Sprint Goal, il PO prioritizza il Product Backlog e seleziona i Product Backlog Item (PBI) più importanti o ne scrive di nuovi.
• Lo Scrum Team formula congiuntamente una Definition of Ready (DoR), che definisce quali caratteristiche o quale livello di dettaglio devono avere i Product Backlog Item affinché il Development Team possa includerli in uno Sprint.

Ora è il momento di condurre il Backlog Refinement Meeting:

• Il Product Owner e il Development Team discutono gli Sprint Goal e i PBI associati. È importante che il PO comunichi solo l’obiettivo da raggiungere e non specifichi come raggiungerlo.
• Il Development Team fornisce il proprio contributo. Questo include da un lato le proprie idee per l’implementazione, basate sulla conoscenza dell’applicazione o del prodotto, e dall’altro commenti sulle dipendenze tecniche tra i PBI, in base ai quali alcuni argomenti vengono ancora ripriorizzati.
• Non appena il Development Team e il PO hanno raggiunto una comprensione comune di un Product Backlog Item, il PO o un membro del team documenta questo PBI secondo la DoR formulata al punto 3 e annota, ad esempio, i criteri di accettazione. Molti team eseguono in questo momento anche la stima dello sforzo – la chiamano Estimation Poker anziché Planning Poker, poiché non avviene nel contesto del

Perché il Product Backlog Refinement (Grooming) è necessario per il successo?

Un buon Product Owner prende il Refinement molto seriamente. Sa che un Backlog Grooming regolare e serio getta le basi per il corso dello Sprint successivo e quindi per il successo di un prodotto, perché:

• Il Refinement assicura che il Product Backlog sia aggiornato e possa essere utilizzato come base per il prossimo Sprint Planning.
• Questo tipo di lavoro preliminare consente al Development Team di occuparsi dei PBI più importanti in una fase precoce e di porre domande che altrimenti emergerebbero solo durante lo Sprint Planning. Questo dà al PO l’opportunità di trovare le risposte in tempo per il Planning Meeting.
• I meeting di Sprint Planning diventano più brevi, perché ora si deve discutere solo il "come" dell’implementazione, dato che il "cosa" è stato chiarito dal Refinement. Inoltre, idealmente i PBI sono già stati stimati dal team e possono essere selezionati in base alla velocity. Ciò evita che non siano disponibili abbastanza PBI preparati nello Sprint Planning.
• Occupandosi insieme dei PBI, il PO e il Development Team sviluppano più rapidamente una comprensione comune della visione, degli obiettivi e dei compiti. Tutte le idee del Development Team per l’implementazione di un PBI vengono annotate nel Refinement.
• Si verifica un enorme trasferimento di conoscenza, poiché il PO fornisce al team sempre più contesto su clienti, modello di business ecc. attraverso il Refinement.
• Nello Sprint, il team può concentrarsi maggiormente sul lavoro effettivo, perché le domande più importanti sono state chiarite nel Refinement.

Ecco a cosa dovresti prestare attenzione durante il Product Backlog Refinement!

• Prima di poter finalmente prioritizzare o ordinare i PBI nel Product Backlog, dovresti avere un’idea dell’entità dei singoli elementi, perché questo determina i costi, che a loro volta influenzano la priorità. In Scrum, l’entità viene stimata in unità di misura relative come gli Story Point.
• Scrum non specifica quando e con quale frequenza si debba eseguire il Product Backlog Refinement. La nostra raccomandazione è: 1 volta a settimana, ad esempio a metà Sprint. Alcuni team eseguono invece Refinement giornalieri e più brevi, il che dipende principalmente dalla disponibilità del Product Owner.
• Come per gli eventi e le altre attività in Scrum, si raccomanda che anche i Product Backlog Refinement vengano eseguiti regolarmente secondo un ritmo fisso, affinché si sviluppi una routine.

Conclusione sul Product Backlog Refinement

Un Product Backlog Refinement regolare e pulito è assolutamente essenziale per uno Sprint di successo – e quindi per il successo del prodotto. Se lavori già come Product Owner o desideri prepararti per questo entusiasmante ruolo e praticare il Product Backlog Refinement, saremo lieti di supportarti con un training per Product Owner adeguato.