Creare e mantenere il Product Backlog

Alla base di qualunque sviluppo agile e, in particolare, in quelli gestiti con il metodo Scrum c’è un Product Backlog ben costruito e gestito.

Il Product Backlog deve essere costituito da funzionalità (o user story) anziché attività e task.

Inoltre ogni funzionalità dovrebbe avere una priorità assegnata in base al valore creato e stimato in story point.

Un elemento chiave per il successo di un progetto di sviluppo è garantire la giusta quantità di dettagli per ciascuna delle componenti presenti nel Product Backlog che dovrebbero corrispondere almeno alle funzionalità da sviluppare nei primi due sprint (iterazioni).

Questo consente di avere una riserva pronta di lavoro da fare nel caso in cui il team di sviluppo dovesse completare in anticipo uno sprint e inoltre dà un vantaggio nella pianificazione dello sprint successivo.

La quantità di dettagli che è necessario esaminare quando si descrivono le componenti del Product Backlog e le decisioni sull’utilizzo di user story o casi d’uso dipende in realtà da scelte del Team di sviluppo.

La responsabilità di gestire il Product Backlog è del Product Owner e il successo nel progetto dipende molto dal modo in cui sono definiti gli elementi contenuti nel Product Backlog.

Un Product Backlog ben definito consente infatti di risparmiare tempo e denaro.

Creazione del Product Backlog

Per creare il Product Backlog (PB) è consigliabile procedere come segue:

1. Scrivere un elenco di funzionalità che devono essere sviluppate per conseguire gli obiettivi del progetto.
2. Descrivere quale sia il risultato desiderato per ogni funzionalità.
3. Assegnare una priorità a ciascuna funzionalità in base al valore creato.
4. Partendo dalla roadmap del prodotto, definire un piano dei rilasci per le funzionalità, che devono essere raggruppate in una determinata versione del prodotto per essere consegnate.
5. Selezionare abbastanza elementi del PB per essere sviluppati in un paio di Sprint.
6. Organizzare un incontro con lo Scrum Team per discutere ciascuno degli articoli definiti nel Product Backlog e fare in modo che lo Scrum Team fornisca una stima di alto livello per ciascun articolo.
7. Rivedere il PB e, se necessario, aggioranre le priorità e il piano dei rilasci.

Seguire questi passaggi consente di disporre di tutte le informazioni necessarie affinché il Team di sviluppo possa effettuare la pianificazione dello Sprint.

Manutenzione del Product Backlog

E’ importante non cadere nella trappola di pensare che una volta creato il Product Backlog, non ci sia bisogno di rivederlo.

Il Product Owner è responsabile del Product Backlog e dovrebbe occuparsi di migliorare e perfezionare il Backlog.

Un aspetto importante è la verifica costante che le user story presenti nel backlog siano pronte per essere lavorate e collocate nello Sprint Backlog. In tal senso, occorre verificare che siano conformi a quanto descritto nella Definition of Ready.

Mantenere un Product Backlog non è facile ed occorre perfezionarlo nel tempo per assicurare consistenza agli sviluppi previsti. Per questo motivo devono essere pianificati periodicamente dei Backlog Refinement Meeting.

Per mantenere il Product Backlog (PB) è opportuno seguire i seguenti passaggi:

1. Una volta che è stato pianificato lo Sprint ed è stato costruito lo sprint backlog, è consigliabile rivedere sistematicamente anche il PB.
2. Se gli elementi contenuti nel PB diventano a priorità più alta e vengono quindi spostati nello sprint successivo, è opportuno verificare che il livello di descrizione delle funzionalità sia completo
3. Se vengono introdotte nuove funzionalità nel PB, occorre chiedere al team di sviluppo di stimarle in story point prima della successiva riunione di pianificazione dello Sprint.
4. Di tanto in tanto, verificare con il Team che le componenti del PB siano descritte con il giusto livello di dettaglio.