Il media che reinventa l'impresa
Il media che reinventa l'impresa
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.
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 :
La traduzione di backlog refinement in italiano è la rifinitura del backlog.
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.
Chi dovrebbe partecipare a questa riunione? Tutti i membri del team Scrum devono partecipare:
👉 Il Product Owner è responsabile della preparazione, dell'organizzazione e della conduzione della riunione di backlog refinement.
Svolgere regolarmente delle riunioni di backlog refinement presenta molti vantaggi:
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.
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.
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 :
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.
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:
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.
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?
