Product backlog: mi piace perché… [parte 1]

Rispetto al più classico documento di requisiti il product backlog è un artefatto che a mio parere offre enormi vantaggi sia nella definizione del prodotto sia nella conduzione di progetto.
Il motivo principale è dovuto al fatto di essere un oggetto evolutivo frutto di un’elaborazione collettiva, che ha quindi maggiori chanches di adattarsi ai cambiamenti (di obiettivi di business, di mercato di riferimento, di framework tecnologico, ecc.).

I vantaggi che ho sperimentato nel suo utilizzo possono essere riassunti in 8 punti principali che vado ad illustrare.

Visione globale

E’ un riferimento unico che descrive il prodotto nella sua totalità dalla prospettiva di tutti coloro che interagiscono con esso (utenti finali, clienti, responsabili del business, ecc.). In questo senso offre una visione complessiva delle funzionalità e, allo stesso tempo, ne dichiara i soggetti beneficiari.

Lettura a più livelli
Qualunque sia lo strumento che viene utilizzato per tracciare il product backlog (dai più sofisticati software ad hoc al banale excel) se la compilazione avviene in modo corretto l’articolazione in epiche, temi e storie consente al lettore di farsi un’idea molto velocemente del prodotto da realizzare.
Attraverso le epiche si colgono le macro-funzionalità; i temi permettono di individuare i dettagli principali di tali funzionalità; le storie definiscono gli attori e i bisogni che vengono soddisfatti.
E’ quindi possibile una lettura a più livelli dal generale al particolare.

Ordinamento per priorità di business
Il fatto che le storie contenute nel product backlog siano ordinate secondo priorità di business consente a chiunque (membro del team, stakeholder, ecc.) di comprendere quali siano i principali risultati attesi dallo sviluppo e gli obiettivi immediati. Non si tratta solo di una guida operativa per ciò che dev’essere implementato (ovvero del “cosa”), ma di una più ampia condivisione degli scopi (del “perché”).

Gestione efficace dello “scope”

In contesti di sviluppo agili i tempi e la qualità del prodotto finale non sono oggetto di alcun tipo di compromesso. Il parametro che varia in funzione degli obiettivi individuati mano a mano è l’ambito di implementazione (il cosidetto “scope” di progetto) sul quale il team lavora nel corso dell’iterazione.
Il product backlog con la segmentazione delle funzionalità di dettaglio in user stories e la condivisione di un ordine di priorità consente al Product Owner e al team di lavoro una gestione più “fluida” e consapevole dello scope rispetto a quanto avviene con un monolitico documento di requisiti.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.