Il Product Backlog Refinement

Una delle attività più importanti ma spesso trascurate in Scrum è il Backlog Refinement, chiamato anche impropriamente "Backlog Grooming". Il verbo inglese "to refine" significa "perfezionare", e "to groom" traducibile con "spazzolare" assume lo stesso significato in senso figurato.

In un aggiornamento del 2013, la guida di Scrum ha però rimosso il termine "grooming" in quanto può assumere connotazioni negative. È preferibile quindi utilizzare la parola "refinement". Inoltre la guida di Scrum non ne stabilisce le modalità precise di esecuzione. Nella realtà dei fatti, il Backlog Refinement, è un meeting con cadenza regolare in cui Product Owner e team di sviluppo collaborano per "perfezionare" il Product Backlog.

Che cos'è il Backlog Refinement

Qualsiasi termine tu decida di utilizzare, io preferisco "backlog refinement", non dovrebbe mai mancare nel calendario delle attività di uno Scrum Team.

La guida di Scrum definisce questa attività come "[...] l'atto di scomporre e definire ulteriormente gli elementi del Product Backlog in elementi più piccoli e più precisi".

Il refinement non è descritto come un evento time-boxed e non è presente nelle cerimonie ufficiali. Per comodità viene spesso svolto sotto forma di meeting, ma nulla vieta al team Scrum di trovare altre tecniche che ritengono più appropriate o efficaci. L'importante è questa attività sia finalizzata ad "aggiungere dettagli, come la descrizione, l'ordine e la dimensione" ai product backlog item.

Se vuoi un esempio di attività per rendere il refinement più efficace e più collaborativo, dai un'occhiata al mio articolo su story mapping.

Scopo del refinement meeting

Come detto nel paragrafo precedente, lo scopo del meeting è di passare in rassegna i product backlog item all'interno del Product Backlog. E definirli ulteriormente, aggiungendo descrizione, ordine (priorità) e dimensione (stime). Per product backlog item si intende per esempio user story, defect o requisiti non funzionali.

Ovviamente lo scopo non è di passare in rassegna tutto il Product Backlog, ma solo quegli elementi che si prevede verranno inclusi nell'iterazione successiva o al massimo entro due Sprint. È responsabilità del Product Owner definire o rendere chiare le priorità e gli obiettivi.

Il refinement include quindi attività quali:

• Rendere chiare le priorità, riordinando i product backlog item in base agli obiettivi definiti dal Product Owner
• Stimare nuove user story o user story esistenti
• Rivedere le stime di user story esistenti alla luce di nuovi requisiti
• Scomporre le user story più grandi (dette Epics) in user story più piccole
• Rimuovere le user story non più rilevanti
• Aggiungere o aggiornare gli acceptance criteria

È importante sottolineare che la stima e la definizione delle attività non possono essere effettuate da Scrum Master e Product Owner. Il refinement richiede la partecipazione dei Developer dello Scrum Team. Product Owner e Scrum Master partecipano alla stima dei requisiti soltanto se sono anch'essi sviluppatori.

Il Product Backlog Refinement è dunque un atto di collaborazione continua tra Product Owner e i Developer. Come già accennato, viene comunemente svolto sotto forma di riunione a cadenza regolare, in cui tutto il team, o una rappresentanza di esso, è presente e attivo nella discussione; ma nulla vieta di svolgere il refinement in forme diverse: per esempio, potrebbe essere svolto come "workshop" verso il termine dello Sprint.

Come si svolge il refinement meeting

Il team, o come dicevamo una rappresentanza di esso, si riunisce entro il termine dello Sprint. In caso di iterazioni lunghe, è bene avere più di un refinement per Sprint. Il Product Owner deve essere presente, in modo da chiarire tutti gli aspetti necessari affinché il team sia in grado di effettuare le stime o le attività necessarie.

Product Owner e Developer lavorano quindi insieme e in particolare:

• Il Product Owner fornisce dettagli e risposte a domande sul "perché"
• Gli sviluppatori forniscono dettagli e rispondono a domande sul "come"

Le stime dei requisiti vengono in genere effettuate mediante planning poker, come descritto nell'articolo: Planning poker, la stima agile di requisiti. Ma nulla vieta di utilizzare metodi alternativi. Con questo metodo, alle user story vengono assegnati gli story point che ne identificano l'effort necessario alla realizzazione.

In seguito all'aggiornamento di fine 2020, la guida ufficiale di Scrum non suggerisce più quanto tempo dedicare al refinement. L'esperienza insegna che il refinement occupa in genere tra il 5% e il 10% della durata dello Sprint; ma è bene non porre limiti e se necessario allocare più tempo.

Il lavoro si svolge sul Product Backlog e non sullo Sprint Backlog, vale a dire che il focus della riunione è sulle attività future e non su quelle in corso.

È importante però sottolineare che il refinement non è un "gate" all'interno dello Sprint. Nulla vieta di pianificare anche se l'attività di refinement non ha portato a risultati soddisfacenti. In questo caso Product Owner e Developer continueranno a lavorare insieme, durante lo Sprint, sui backlog item su cui persistono dubbi o ambiguità.

Chi partecipa al Backlog Refinement

A questo punto avrai compreso che Product Owner e Developer sono gli attori principali del refinement, e utilizzano questa attività per aggiungere dettagli agli elementi del Product Backlog. Non è obbligatorio che tutti gli sviluppatori del team partecipino, anche se è consigliabile, dato che l'intero team di Developer è responsabile per la qualità delle informazioni e delle stime fornite.

È importante che in caso alcuni sviluppatori decidessero di non partecipare, le persone presenti siano in grado di garantire un buon esito della sessione di refinement.

Lo Scrum Master non è richiesto ma potrebbe indubbiamente rendersi utile facilitando la discussione tra le parti o suggerendo tecniche e strategie per migliorare la conversazione.

Ma chi altro può partecipare? In molti casi il Product Owner potrebbe decidere di invitare alcuni stakeholder che sono interessati allo sviluppo della soluzione e sono in grado di contribuire. Per esempio:

• Product Manager
• Architetti del software
• UX designer
• Business Analyst

In poche parole, chiunque sia in grado di rispondere a domande o aiutare i Developer a raggiungere una comprensione completa del prodotto.

L'importante è che gli stakeholder non influiscano in maniera negativa sul meeting, magari avanzando pretese sulle stime o forzando il team a prendere determinate decisioni tecniche.

Benefici del refinement meeting

Il backlog refinement meeting è un ottimo forum per condividere domande e incertezze, in modo da smarcare quanti più dubbi possibile in vista dello Sprint planning meeting. Nonostante ciò, è utile tenere a mente che il refinement non è un meeting o un evento orientato alla risoluzione dei problemi (o di tutti i problemi). È più che altro uno strumento per verificare che il team abbia in possesso abbastanza informazioni, lo stretto necessario per procedere con la stima delle attività e con la successiva pianificazione.

Il refinement è inoltre efficace per mantenere il Product Backlog sempre aggiornato e con user story stimate in maniera appropriata a seconda delle priorità. Per esempio, se una user story è in cima al Product Backlog e ha quindi priorità alta, la stima dovrà essere quanto più accurata possibile. È invece accettabile avere stime meno accurate, o nessuna stima, per le attività al fondo del backlog.

Alla luce di quanto appena detto, non è fondamentale che tutte le user story siano dettagliate e divise in user story più piccole laddove necessario. Lo scopo del refinement è assicurare che un numero sufficiente di attività, quelle con priorità più alta, siano pronte per la pianificazione.