No, il backlog refinement non è l’ennesima riunione inutile imposta dal framework Scrum… al contrario.
Forse non compare ufficialmente nell’elenco delle cerimonie della guida Scrum, ma sta diventando sempre più un incontro importante per i team agili, che li aiuta ad affrontare con maggiore serenità la pianificazione e l’avanzamento dello sprint successivo.
Cos’è il refinement backlog e come funziona? Vi daremo anche alcuni consigli per un backlog refinement efficace.
Che cos’è il backlog refinement?
Definizione
Per comprendere appieno il backlog refinement, dobbiamo innanzitutto chiarire il concetto di backlog.
Il backlog è un elenco di requisiti di business per un prodotto o un progetto, tradotto in storie utente che descrivono l’esatta esigenza dell’utente. Viene compilato e gestito dal Product Owner e l’intero team lo consulta durante la pianificazione dello sprint per selezionare le storie e le funzionalità che si impegnano a sviluppare durante lo sprint.
Il backlog refinement, o backlog grooming, è l’azione di affinamento del backlog in una riunione dedicata durante lo sprint.
In termini pratici, la rifinitura del backlog comporta:
- Chiarire la comprensione delle storie utente,
- stimare (o ri-stimare) l’impegno necessario per completarle
- Determinare il valore funzionale di ogni US per facilitare la definizione delle priorità,
- rimuovere le US (se necessario),
- aggiungere US (se necessario).
🇫🇷 La traduzione francese di backlog refinement è affinage du backlog.
Raffinamento del backlog vs pianificazione dello sprint
Qual è la differenza tra la riunione di backlog refinement e la pianificazione dello sprint?
La pianificazione dello sprint si svolge il primo giorno dello sprint e mira a definire l’obiettivo dello sprint e a selezionare le storie utente che il team si impegna a consegnare alla fine. Può durare circa 2 ore per ogni settimana di sprint.
Il refinement backlog è una riunione intermedia e complementare alla pianificazione dello sprint. Possono essercene diversi durante lo sprint e il loro scopo è preparare il terreno per la pianificazione dello sprint, che dovrebbe essere più efficace.
Chi sono i partecipanti al refinement backlog?
Tutti i membri del team Scrum devono partecipare a questo incontro:
- il Product Owner,
- lo Scrum Master,
- il team di sviluppo,
- chiunque altro possa essere d’aiuto.
Ma il ruolo di ogni persona non si esaurisce con la sua presenza intorno al tavolo (o allo schermo, per i team video).
Il Product Owner è responsabile della preparazione, dell’organizzazione e della conduzione della riunione di rifinitura del backlog. Fornisce la visione del prodotto e chiarisce gli elementi del backlog. Specifica i requisiti di business, stabilisce le priorità dei PBI e risponde a qualsiasi domanda che possa bloccare il lavoro del team.
Lo Scrum Master assicura che la sessione di backlog rimanga fluida e strutturata. Si assicura inoltre che tutti abbiano voce in capitolo e che il processo segua i principi agili. In un certo senso, lo Scrum Master è il direttore dell’orchestra di perfezionamento.
I membri del team di sviluppo svolgono un ruolo fondamentale, in quanto sono loro a stimare, ritagliare e porre le domande che fanno avanzare il progetto. La loro competenza tecnica consente di anticipare i rischi e di chiarire i compiti prima dello sprint successivo.
Infine, di tanto in tanto si possono invitare altri profili, come un esperto tecnico, un designer UX o persino uno stakeholder. Se la loro presenza aiuta a chiarire un punto poco chiaro, perché privarsene?
Quali sono gli obiettivi del backlog refinement?
L’uso regolare del backlog refinement presenta una serie di vantaggi:
- Questo lavoro preparatorio fornisce tranquillità quando si tratta di pianificare e gestire lo sprint successivo,
- affina la comprensione dei requisiti
- prepara la stima delle User Stories
- consente di fare un bilancio a metà dello sprint,
- può ridurre la durata della pianificazione delle riunioni di sprint.
E non è tutto! Questa riunione agile allinea l’intero team Scrum alle priorità del backlog di prodotto. Il risultato: meno imprevisti, meno rilavorazioni e più valore consegnato in ogni iterazione.
Svolge inoltre un ruolo chiave nel miglioramento continuo. Raffinando gli elementi delbacklog, impariamo a scrivere meglio le storie, a suddividere più finemente i compiti e ad anticipare le dipendenze.
Infine, il perfezionamento riduce le aree grigie. Consente al team di sviluppo di porre al Product Owner tutte le domande necessarie, anche prima dell’inizio dello sprint.
Per quanto tempo e con quale frequenza deve essere effettuato?
Dipende dal team, ma almeno una riunione di backlog refinement di un’ora per ogni sprint.
In un’ottica di agilità continua, tuttavia, è consigliabile organizzarne più di uno, anche se ciò significa ridurne la durata. Ciò consente al Product Owner di anticipare e di avere il tempo di rielaborare gli Stati Uniti prima della fine dello sprint.
Spesso si parla di dedicare circa il 10% del tempo di sviluppo a questo aspetto. Per uno sprintdi due settimane, si tratta di mezza giornata divisa in diverse sessioni di backlog.
I team più esperti preferiscono suddividere il perfezionamento in microsessioni di 30 minuti. Il risultato: maggiore concentrazione, meno riunioni interminabili e un backlog di prodotto sempre aggiornato.
La chiave è trovare il ritmo giusto, in modo che il backlog del prodotto sia sempre pronto per lo sprint successivo. Né troppo presto (non ha senso preparare elementi del backlog che cambieranno), né troppo tardi (il perfezionamento dell’ultimo minuto è una porta aperta al caos!).
Quali sono le fasi del refinement backlog?
Tutto inizia con la preparazione del backlog di prodotto da parte del Product Owner. Seleziona gli elementi del backlog da discutere:
- quelli con la massima priorità
- quelli che non sono chiari
- quelli con una posta in gioco elevata per lo sprint successivo.
Ogni User Story deve essere scritta secondo i criteri INVEST (Independent, Negotiable, Valuable, Estimateable, Sufficiently small, Testable). Altrimenti, attenzione alla confusione in fase di rifinitura!
Il Product Owner può anche precompilare alcune informazioni: criteri di accettazione, esigenze di business o qualsiasi dato utile per rendere più fluido il processo di stima.
Infine, il team deve essere informato in anticipo. Un’agenda condivisa, alcuni documenti preparatori e un rapido promemoria in agenda gettano le basi per una sessione di backlog efficace.
Una buona preparazione fa risparmiare tempo durante la riunione… ed evita di prendere tempo.
Come funziona il backlog refinement
1. Presentazione e comprensione delle storie utente
Come promemoria, è il Product Owner che ha la responsabilità di tradurre una richiesta o un’esigenza dell’utente in una User Story, nel modo più dettagliato e chiaro possibile.
Pertanto, presenterà al resto del team le Storie dell’utente che ha completato, o almeno quelle che sono già a buon punto.
L ‘obiettivo è assicurarsi che i membri del team di sviluppo abbiano una perfetta comprensione del requisito e che possano fare domande e discutere le SDU. Il Product Owner può quindi modificarle o aggiungerle in base alle domande e alle discussioni che si sono svolte.
Il team può quindi convalidare la User Story e passare alla stima.
Se si scopre che il team di sviluppo non comprende la richiesta, il Product Owner dovrà dedicare del tempo a rielaborare e chiarire le sue US per ripresentarle alla sessione successiva.
2. Affinare la stima
Il passo logico successivo alla convalida dei requisiti è la stima da parte degli sviluppatori.
Ogni team ha i propri metodi e strumenti per stimarli, ma in pratica si tende a stimare una US in punti di sforzo piuttosto che in tempo.
I metodi più comunemente utilizzati sono :
- pianificazione del poker
- la dimensione della maglietta,
- il sistema dei secchi.
Sta a voi decidere quale metodo si adatta meglio al vostro team e ai vostri progetti. Se si scopre che una User story diventa complicata da stimare, è meglio suddividerla in diverse US più piccole per vedere le cose più chiaramente.
💡 Buono a sapersi: stimiamo (o ristimiamo) le User Story per lo sprint successivo, o eventualmente per quello dopo, ma evitiamo di stimare più avanti.
3. Privilegiare le voci del backlog
Conoscere la stima di una User Story consente al team di iniziare a stabilire le priorità.
Tuttavia, si possono prendere in considerazione altri criteri di priorità, in particolare il valore funzionale, che è essenziale. Ecco perché è ingegnoso determinare i livelli di priorità in base al rapporto valore/sforzo:
- priorità 1 (P1): alto valore aziendale e facile da sviluppare,
- priorità 2 (P2): alto valore aziendale e difficile da sviluppare,
- priorità 3 (P3): basso valore commerciale e facile da sviluppare,
- priorità 4 (P4): basso valore aziendale e difficile da sviluppare.
Il team assegna quindi un ordine di priorità agli Stati Uniti, tenendo presente che l’obiettivo principale è fornire il massimo valore nel più breve tempo possibile.
Buono a sapersi: la prioritizzazione può essere fatta su tutto il backlog anche se gli USA non sono tutti completi, perché siamo in una visione più macro.
Suggerimenti finali per un refinement backlog efficace
- Suggerimento n. 1: in qualità di Product Owner, preparate la presentazione delle Unità di Rilascio in modo meticoloso, spiegando al team il vostro pensiero, il contributo che ritenete possa dare, ecc. Più siete entusiasti e chiari, più è probabile che il team accetti la vostra visione del prodotto e convalidi le US.
- Suggerimento 2: Accettate domande, commenti e feedback negativi. Troverete sicuramente qualcosa di costruttivo da aggiungere al vostro pensiero e quindi al vostro US.
- Suggerimento n. 3: non aspettate l’ultimo momento e la fine di tutti gli Stati Uniti per creare il backlog di perfezionamento. È meglio presentare regolarmente le storie finite, durante i backlog di perfezionamento rapido, in modo da poter anticipare se è necessario lavorarci sopra, altrimenti si rischia di compromettere lo sprint successivo. Evitate l’effetto tunnel!
Caso di studio sull’applicazione del backlog refinement nel mondo degli affari
Immaginate un team di sviluppo di una start-up tecnologica, nel bel mezzo della riprogettazione del suo sito web. Il Product Owner ha appena ricevuto una raffica di feedback dagli utenti: navigazione confusa, lentezza su mobile, mancanza di accessibilità.
Piuttosto che gettare tutti questi elementi del backlog nella mischia della pianificazione dello sprint, il team organizza una sessione dedicata al backlog.
Durante il refinement backlog, ogni User Story viene analizzata:
- “Migliorare il tempo di caricamento dei dispositivi mobili”,
- “Aggiungere un menu accessibile da tastiera”,
- “Rivedere la struttura ad albero della home page”.
Gli sviluppatori fanno domande, gli UX designer suggeriscono soluzioni, il Product Owner di chiarisce gli obiettivi e riformula alcune esigenze. Insieme, valutano la complessità dei requisiti e riorganizzano l’ elenco in base al valore aziendale.
Il risultato: un backlog di prodotto chiaro, PBI ben calibrati e un lancio senza problemi dello sprint successivo. Meglio ancora, il team Scrum ha guadagnato in coesione… e tranquillità.
L’arte di prepararsi per una consegna migliore
Il backlog refinement di non è solo un’altra riunione del calendario. È un momento chiave per :
- fare un passo indietro
- porre le domande giuste
- costruire un solido backlog di prodotto.
Raffinando regolarmente le Storie dell’utente, si rende più fluido il prossimo sprint, più rilassato il team di sviluppo e più prevedibili le consegne. In breve, si passa alla modalità agile con la A maiuscola.
