Tag: grooming

Riprendiamo il discorso sui principali vantaggi derivanti dall’utilizzo del Product Backlog rispetto alla classica documentazione di progetto (documento di requisiti, documento di specifiche funzionali, ecc.).
Ho già illustrato in un post precedente quali sono i benefici in termini di visione globale del prodotto, lettura a diversi livelli di profondità e dettaglio dei requisiti, ordinamento degli stessi in base alle priorità di business e gestione dello scope.
Oggi vorrei approfondire quelle caratteristiche che a mio parere rendono il Product Backlog un oggetto estremamente duttile ed adattabile ai cambiamenti di scenario, di business e di frame tecnologico di riferimento.

Elaborazione progressiva
Uno dei vantaggi tangibili consiste nel fatto che il Product Backlog è in continua evoluzione prima, durante e dopo il rilascio del prodotto sul mercato.
In particolare una delle considerazioni su cui desidero soffermarmi è che il Product Backlog all’inizio di un progetto non ha necessità di essere pienamente esaustivo e definito al 100%. E’ possibile partire con l’implementazione tecnologica dei primi macro-requisiti e mettere a fuoco progressivamente le funzionalità del prodotto.
Se qualcosa non è stato definito in prima battuta può essere accolto strada facendo secondo un processo autocorrettivo.

Aggiornamento continuo
Se da una parte non ha la necessità di essere “blindato” e “scritto col sangue” all’inizio di un progetto, dall’altra non smette mai di evolvere.
 Un Product Backlog non è mai completo: definisce chiaramente solo ciò che è oggetto di implementazione nei cicli di sviluppo immediatamente successivi.
Allo stesso tempo al termine di ogni iterazione e sulla base dei feedback raccolti nel corso dello Sprint Review può arricchirsi mano a mano di nuovi elementi.
Questa permeabilità agli stimoli esterni fa sì che la direzione dello sviluppo di un prodotto possa essere rivista più volte dal cliente ancora prima del primo rilascio in produzione.

Frutto di un lavoro collaborativo
Il Backlog nasce da un lavoro di gruppo che nelle fasi iniziali di concept del prodotto comprende il Product Owner, lo Scrum Master e gli stakeholder.
 Successivamente, dal momento in cui viene istituito un team ed il Backlog diventa il riferimento primo del lavoro da realizzare, diviene un oggetto di rielaborazione, grooming e brainstorming collettivo.
Tutte le persone del gruppo diventano mano a mano più consapevoli delle finalità del prodotto e hanno la possibilità di portare sul tavolo i propri spunti e suggerimenti, così come di accogliere contributi di valore provenienti dall’esterno.
Il prodotto finale è il risultato dell’applicazione di un’intelligenza collettiva.

Segue l’intero ciclo di vita del prodotto
“Finché esiste un prodotto esiste anche il suo Product Backlog”, così recita la Scrum Guide di Schwaber e Sutherland.
A differenza di un documento di specifiche che decade con il rilascio online di un progetto (e a volte “muore” molto prima per mancato aggiornamento), il Backlog viene manutenuto durante l’intero ciclo di vita del prodotto.
Le esigenze di adattamento, modifica ed evoluzione che emergono una volta che il prodotto è immesso sul mercato sono registrate mano a mano come nuovi requisiti nel Product Backlog.
Non vengono redatti nuovi documenti, il riferimento rimane sempre il medesimo per tutti  gli attori in causa sino alla dismissione definitiva del prodotto.

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.