Che cos'è l'Product Backlog Refinement?

La Guida Scrum la definisce come l'atto di scomporre e definire ulteriormente gli elementi Product Backlog in elementi più piccoli e precisi.

Product Backlog Refinement si riferisce al mantenimento del Backlog pulito e ordinato. Nella Guida di Scrum viene definito come l'atto di scomporre e definire ulteriormente le voci Product Backlog in voci più piccole e precise. 

Si tratta di un processo continuo in cui l'Product Owner e il team di Developer collaborano per garantire che le voci del Backlog siano: 

  • Compreso allo stesso modo dal team (ha una comprensione condivisa).
  • Ha una stima delle dimensioni e della complessità dell'implementazione.
  • Ordinati in base alla priorità (compresi il valore aziendale e la stima).

In parole povere, il Backlog Refinement è incentrato sulla creazione di una comprensione condivisa di ciò che il prodotto farà o non farà, sulla stima di ciò che sarà necessario per costruirlo e implementarlo e sull'ordine di esecuzione. 

Vale anche la pena di notare che, contrariamente ad altre Eventi ScrumL'affinamento Product Backlog non è a tempo. Questo perché non ha una sequenza specifica all'interno del framework Scrum. Se fosse vincolata a un time-box, l'attività non sarebbe efficace. Tuttavia, una regola empirica è che è possibile utilizzare fino a 10% del tempo in un Sprint per il perfezionamento, che deve essere effettuato quando necessario e spesso è incluso in una "riunione di perfezionamento".

Diamo un'occhiata all'Product Backlog Refinement in modo più dettagliato.

La riunione di perfezionamento

Come già accennato, l'Product Backlog Refinement viene solitamente svolto nell'ambito di una riunione di rifinitura. Il team Scrum si riunisce una volta, di solito verso la fine del Sprint per questo evento, per garantire che il Backlog sia pronto per il successivo Sprint. Tuttavia, in alcuni casi, i team possono scegliere di riunirsi una volta alla settimana per tenere sotto controllo la situazione.

Una riunione di perfezionamento è un'opportunità per la Product Owner per condividere quali elementi del Product Backlog devono essere perfezionati e per consentire al team di discuterne. Durante questo momento, il team può porre domande che altrimenti non si presenterebbero fino al Sprint Planning. Non è necessario che tutte le domande vengano risolte nella riunione di rifinitura del Backlog, ma questo dà al Product Owner un vantaggio prima della riunione di pianificazione.

Il Backlog Refinement è essenzialmente un punto di controllo per il team piuttosto che uno sforzo per risolvere completamente i problemi.

Chi è responsabile dell'Product Backlog Refinement?

Ogni membro del team Scrum è responsabile dell'Product Backlog Refinement, ma di solito avviene su iniziativa dell'Product Owner. Di seguito è riportata una suddivisione di ciascun membro del team e delle sue responsabilità principali: 

  • L'Product Owner: costruire la cosa giusta
  • Gli Developer: costruire bene l'apparecchio
  • L'Scrum Master: allenare e guidare la squadra

Il modello Product Owner

Il Product Owner ha autorità e responsabilità sull'Product Backlog. Un perfezionamento efficace deve partire dalla visione e dal "perché" del prodotto. Deve garantire la trasparenza di questa visione e consentire discussioni aperte sia con il team che con gli stakeholder. 

Le seguenti attività possono essere utili per l'Product Backlog Refinement. È opportuno che sia l'Product Owner ad avviarle, ma anche altri membri del team possono farlo: 

  • Creare una visione del prodotto
  • Impostazione di una road map del prodotto 
  • Realizzare uno storyboard
  • Collaborare con le parti interessate e i clienti sull'utilizzo del prodotto. 
  • Effettuare ricerche di mercato
  • Definizione degli obiettivi 
  • Definizione di criteri di accettazione o di soddisfazione

Gli Developer

Gli Developer dovrebbero essere responsabili anche dell'Product Backlog Refinement. Può essere molto utile per loro sentirsi responsabili del perfezionamento insieme agli Product Owner. Dopotutto, sono gli sviluppatori a portare a termine il lavoro. 

I seguenti esempi sono solo alcune delle attività che dovrebbero essere di competenza dell'Developer: 

  • Stima degli articoli Product Backlog per avere una visione d'insieme di ciò che può essere completato in un Sprint 
  • Trovare soluzioni per soddisfare l'Sprint Goal
  • Collaborare con altri Developer per condividere le conoscenze. 
  • Documentare le soluzioni per il lavoro

Il modello Scrum Master

Infine, il Scrum Master è responsabile di garantire che il team comprenda Scrum. In questo caso, le sfide del perfezionamento e che tutti abbiano chiaro il proprio ruolo. Inoltre, il Scrum Master deve contribuire a facilitare le attività di affinamento e aiutare tutti a concentrarsi sul proprio ruolo. 

Alcuni esempi possono essere: 

  • Facilitare i workshop Product Backlog Refinement
  • Insegnare l'importanza della responsabilità condivisa in questo compito. 
  • Insegnare al team le modalità di consegna e di collaborazione 

A volte gli stakeholder possono essere invitati a partecipare alle riunioni di perfezionamento o a fornire input e feedback, ma la responsabilità è sempre del team Scrum interno.

Sintesi

Product Backlog Refinement è un aspetto importante di ogni Sprint. Senza una comprensione condivisa, c'è il rischio di implementare le cose sbagliate e di sprecare gli sforzi. È importante tenere conto della dimensione di ogni elemento, che aiuta a ordinare le Product Backlog in termini di priorità. In mancanza di ciò, i team rischiano di lavorare su elementi che non sono importanti e di tralasciare quelli che lo sono. 

È quindi importante che l'intero team abbia una buona conoscenza dell'Product Backlog Refinement e possa collaborare efficacemente durante la riunione di rifinitura.

Condividi:

Post del blog correlati

10 vantaggi dell'utilizzo delle Sprint Goal

Noi di Better Change crediamo nel potere della collaborazione tra team per creare valore nelle organizzazioni. Un aspetto importante e spesso trascurato è l'uso delle Sprint Goal. Si tratta di obiettivi chiari e concisi stabiliti per ogni Sprint che forniscono direzione e concentrazione ai team Scrum.

Miscomunicazione nelle specifiche del software.

Nei documenti di specifica del software si verificano spesso dei malintesi. La soluzione che di solito si sceglie è quella di creare specifiche più dettagliate. Purtroppo questo non porta a risultati migliori.

Formazione correlata

Risorse correlate

Come gestire una Retrospettiva

L'esecuzione di una retrospettiva efficace è fondamentale per il miglioramento continuo dei team Agile. Se vi è capitato di pensare che le retrospettive del vostro team non abbiano una direzione o non riescano a produrre informazioni utili, siete...

Il processo Scrum spiegato

Scoprite le complessità del processo Scrum e imparate come questo framework agile può rivoluzionare la gestione dei progetti.

Altre risorse

Parliamo di
come possiamo aiutarti!

Ti piacciono i nostri articoli? Ancora meglio, puoi parlare con noi di persona! Contattaci per fissare un appuntamento!