Backlog refinement: la riunione Scrum per uno sprint più efficace
No, il backlog refinement non è un'altra riunione inutile imposta dalla metodologia Scrum....ma si può rivelare molto utile.
Anche se non è menzionato ufficialmente nella guida Scrum, sta diventando sempre più importante nei team agili, per affrontare con calma la pianificazione e il progresso dello sprint imminente.
Cos'è il backlog refinement e come funziona? Vi diamo anche alcuni consigli per un svolgere un backlog refinement che faccia la differenza.
Cos'è il backlog refinement?
Definizione
Per comprendere appieno il backlog refinement, dobbiamo prima essere chiari sul concetto di backlog.
Il backlog è una lista di requisiti di business per un prodotto o un progetto, tradotta in User stories che descrivono precisamente i bisogni dell'utente. È creato e gestito dal Product Owner, e tutto il team lo consulta durante il processo di pianificazione dello sprint per selezionare le stories e le caratteristiche che svilupperanno durante lo sprint.
Il backlog refinement, o backlog grooming, è l'azione di rifinitura del backlog in una riunione dedicata durante lo Sprint.
In termini concreti, il backlog refinement consiste nel :
- chiarire la comprensione delle user stories,
- stimare (o ri-stimare) lo sforzo richiesto per completare il progetto,
- determinare il valore funzionale di ogni User Stories per facilitare la prioritizzazione,
- rimuovere alcune user stories (se necessario),
- aggiungere alcune user stories (se necessario).
La traduzione di backlog refinement in italiano è la rifinitura del backlog.
Backlog refinement rispetto alla pianificazione dello sprint
Qual è la differenza tra la riunione di backlog refinement e la pianificazione dello sprint?
La pianificazione dello sprint ha luogo il primo giorno dello sprint, e mira a definire l'obiettivo dello sprint così come a selezionare le User stories che il team si impegna a consegnare alla fine. Può durare circa 2 ore per settimana di sprint.
Il backlog refinement è una riunione intermedia e complementare alla pianificazione dello sprint. Ce ne possono essere diversi durante lo sprint, e il loro scopo è quello di preparare il terreno per la pianificazione dello sprint, che dovrebbe essere più efficace.
Partecipanti
Chi dovrebbe partecipare a questa riunione? Tutti i membri del team Scrum devono partecipare:
- il Product Owner,
- lo Scrum Master,
- il team di sviluppo,
- qualsiasi altra persona che possa aiutare.
👉 Il Product Owner è responsabile della preparazione, dell'organizzazione e della conduzione della riunione di backlog refinement.
Obiettivi
Svolgere regolarmente delle riunioni di backlog refinement presenta molti vantaggi:
- questo lavoro preparatorio facilita la pianificazione e nel progresso dello sprint successivo,
- affina la comprensione dei bisogni dei clienti,
- prepara la stima delle User Stories,
- permette di fare una revisione intermedia,
- può accorciare la durata della pianificazione della riunione sprint.
Durata e frequenza
Dipende dal team, ma una riunione di backlog refinement dura un'ora per sprint.
In una logica di metodologia agile al 100%, è comunque consigliabile eseguirne diverse, anche se ciò può comportare una riduzione nella durata delle riunioni. Questo permette al Product Owner di anticipare e avere il tempo di rielaborare le sue user stories prima della fine dello sprint.
Il processo di backlog refinement
1. Presentazione e comprensione delle User Stories
Come promemoria, è il Product Owner che ha la responsabilità di tradurre una richiesta o un bisogno dell'utente in una User Story, il più dettagliata e chiara possibile.
Presenterà quindi al resto della squadra gli User Stories che ha completato, o almeno quelli che sono già a buon punto.
L'obiettivo è quello di assicurare che i membri del team di sviluppo abbiano una perfetta comprensione dei requisiti, e che possano fare domande e discutere delle User Stories. Il Product Owner può poi modificarli o arricchirli in base alle domande e le discussioni che hanno avuto luogo.
Il team può quindi convalidare la User Story e può passare alla sua stima.
👉 Se si scopre che il team di sviluppo non ha compreso la richiesta, il Product Owner dovrà prendere tempo per rielaborare e chiarire le sue User Stories per presentarle di nuovo durante la prossima sessione.
2. Mettere a punta la stima delle User Stories
Il prossimo passo logico dopo la convalida delle User Stories è la loro stima da parte degli sviluppatori.
Ogni team ha i propri metodi e strumenti per stimarli, ma in pratica, una User story è stimata in story points piuttosto che in ore o settimane.
Tra i metodi più comunemente usati, troviamo :
- il poker planning,
- il bucket system.
Sta a voi vedere quale si adatta meglio al vostro team e ai vostri progetti. Se si scopre che una user stories diventa complicata da stimare, è meglio suddividerla in diverse user stories più piccole per comprendere meglio gli obiettivi.
💡 Buono a sapersi: facciamo una stima o una nuova stima delle User Stories del prossimo sprint, o eventualmente di quello successivo, ma non andiamo oltre.
3. Dare la giusta priorità agli item del backlog
Conoscere la stima di una User Story permetterà al team di iniziare il suo lavoro di prioritizzazione.
D'altra parte, altri criteri di priorità possono essere presi in considerazione, specialmente il valore funzionale che è essenziale. Per questo è ingegnoso determinare i livelli di priorità secondo il rapporto valore/sforzo:
- priorità 1 (P1): alto valore commerciale e facile da sviluppare,
- priorità 2 (P2): alto valore commerciale e difficile da sviluppare,
- priorità 3 (P3): basso valore commerciale e facile da sviluppare,
- priorità 4 (P4): basso valore commerciale e difficile da sviluppare.
Quindi il team assegna ordini prioritari a tutte le User Stories, tenendo presente che l'obiettivo principale è quello di fornire il massimo valore il più rapidamente possibile.
💡 Buono a sapersi: la prioritizzazione può essere fatta su tutto il backlog anche se le user stories non sono tutte complete perché in questo caso l’analisi si svolge a livello macro.
Suggerimenti finali per un backlog refinement efficace
Primo suggerimento: Come Product Owner, preparate la presentazione delle User Stories in dettaglio spiegando al team le vostre idee, le modifiche che potremmo incontrare i bisogni dei clienti, ecc. Più siete entusiasti e chiari, più è probabile che il team condivida la vostra visione del prodotto e convalidi le user stories.
Secondo suggerimento: Accetta domande, commenti e feedback negativi. Troverete sicuramente qualcosa di costruttivo che arricchirà il vostro pensiero e quindi le vostre User Stories.
Terzo suggerimento: Non aspettate fino all'ultimo momento e fino a quando non avete finito tutte le vostre user stories per fare il backlog refinement. È meglio presentare regolarmente le user stories completate durante i rapid refinement backlogs per anticipare se hanno bisogno di essere lavorate, altrimenti lo sprint successivo può essere compromesso. Evitare l'effetto tunnel!
E voi? Avete qualche consiglio per un Product Owner che sta iniziando il suo viaggio verso il backlog refinement?