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.