Che cos’è il PBI (Product Backlog Item) in Scrum

Perché le storie utente?

In un altro articolo, abbiamo già avuto modo di accennare che il framework Scrum non fornisce alcuna indicazione sul formato da usare per la definizione degli elementi del Product Backlog; nella pratica diffusa, però, è ormai universalmente utilizzato il formato delle User Stories (US), preferito sia per la semplicità che per la capacità di adattarsi al processo di lavorazione di Scrum.

Una storia utente esprime un bisogno di business dal punto di vista dell’utente, tramite un linguaggio naturale, comprensibile sia dal personale tecnico che da utenti e/o esperti di dominio.
Il processo utilizzato per la creazione e le successive modifiche dei requisiti tramite user stories segue un processo incrementale basato su iterazioni e raffinamenti: nella compilazione di una storia si parte dal definire in modo sintetico e ad alto livello le funzionalità che si dovranno implementare per rispondere al bisogno di business in questione. Esula dagli obiettivi della storia utente affrontare i dettagli tecnici, del design o dell’analisi di dettaglio della funzionalità.

Elementi del Product Backlog e PBI

All’interno del Product Backlog il team inserisce tutti gli elementi (Product Backlog Items, PBI) necessari per il completamento del prodotto; vi si possono trovare quindi storie ma anche bugs, requisiti tecnici, idee e items.
Gli elementi del Product Backlog sono classificati in base alla grandezza o al livello di dettaglio: quelli grandi e a grana grossa definiscono un ampio spettro di funzionalità e sono spesso detti Epiche, proprio per evidenziarne la maggiore dimensione, con le quali si indicano parti principali di funzionalità del sistema (ad esempio: “Catalogo prodotti”).

Il processo di scomposizione delle epiche porta a qualcosa di più piccolo detto Features. Anche le Features sono ancora troppo grandi per essere messe in lavorazione all’interno dello sprint: è necessario quindi un ulteriore processo di raffinamento che dà luogo alle cosiddette storie utente o User Stories. Proprio per evidenziare il fatto che sono pronte per la messa in lavorazione, queste sono dette a volte Sprintable Stories, che in italiano si potrebbe tradurre con storie lavorabili in uno sprint, anche se questa definizione non è parte della specifica ufficiale di Scrum. La definizione di Sprintable Stories si ricollega al concetto di Definition of Ready (DoR), ossia una specie di accordo che si stipula a livello di Scrum Team per definire cosa può essere messo in lavorazione nello sprint e cosa no.
Le definizioni di Epic e Feature non sono universalmente adottate, tanto che in alcuni casi si trovano definizioni invertite o basate su termini equivalenti; in questo libro seguiremo questa convenzione, sottintendendo che si tratta appunto di una convenzione.

Differenza tra Epica, Feature e User Story

Un modo per classificare e distinguere Epiche, Feature o semplicemente Sprintable Stories, è quello di dividerle in base al tempo necessario per il completamento: convenzionalmente quindi si dice che una Epica richiede alcuni mesi di lavorazione, una Feature alcune settimane, una User Story qualche giorno di lavoro.
Ovviamente queste dimensioni sono da contestualizzare con la lunghezza scelta per gli Sprint: se per esempio le iterazioni fossero di una settimana, il tempo di lavorazione di una User Story dovrebbe scendere in modo significativo (in genere poche ore). Quindi si potrebbe generalizzare dicendo che una Sprintable Story non dovrebbe superare una dimensione proporzionale a quella dello sprint, per esempio un quarto o un terzo della durata dell’iterazione; c’è chi si spinge addirittura nel suggerire di restare entro il 10% della durata dello sprint.
Una storia dunque può essere ulterioremente scomposta nei suoi sotto-task, attività che sono dell’ordine delle poche ore di lavoro. Come si è avuto già modo di accennare, Scrum non fornisce alcuna indicazione sulla necessità di questa ulteriore scomposizione: è una attività comunque utile, ma dato che i task non danno valore al PO, la loro scomposizione normalmente è lasciata in carico al Dev Team; i task possono essere visti come una tattica che il team utilizza per raggiungere l’obbiettivo vero, che è finire storie.

Aggiornamento del Product Backlog

Per quanto concerne il ciclo di vita dei suoi elementi, il Product Backlog può essere considerato come una lista di funzionalità in continua evoluzione: elementi grossi e generici (Epiche o Features) sono smontati in elementi più piccoli, dettagliati con maggiori informazioni e quindi spostati verso l’alto. Contemporaneamente, l’acquisizione di nuove conoscenze sul prodotto da sviluppare può portare a una rivalutazione delle priorità degli elementi posizionati nella parte alta del backlog, elementi che possono essere scambiati con altri più in basso o addirittura rimossi dal Product Backlog. Qualora si evidenzi la necessità di aggiungere nuove funzionalità al prodotto finale, può capitare che nuovi elementi siano aggiunti al Product Backlog. Dato che non è possibile prevedere la grana e la dimensione di questi nuovi elementi, è necessario mantenere alta la concentrazione su ciò che viene aggiunto al backlog: più un elemento viene inserito in alto, maggior sarà l’urgenza di raffinarlo e prepararlo per la sua messa in lavorazione in uno dei prossimi sprint.