Tra la fantasia e la realtà, c’è di mezzo il backlog!
Mai affermazione fu più vera.. ma come possiamo gestirlo al meglio?
Quali elementi dobbiamo tenere in considerazione?
Vediamo ora insieme alcune riflessioni e best practicesche ci possono aiutare nel mantenerlo vivo, ordinato e “pulito”.
- Cos’è il Product Backlog?
- Chi alimenta il Product Backlog?
- Qual è la sua dimensione ideale?
- DEEP – Cosa significa?
Cos’è il Product Backlog?
Il Product Backlog è una lista ordinata di tutto ciò che deve essere, o vorresti che venisse, fatto per il tuo prodotto.
Detta così, sembra quasi una sorta di to-do-list di attività che il team deve eseguire ma vi posso assicurare che non è così.
Cominciamo a destreggiarci tra gli elementi che lo caratterizzano.
- Esprimere obiettivi, bisogni o risultati da raggiungere.
- L’ordine degli elementi è fondamentale.
- Backlog, RoadMap, Vision.
- Condivisione e Trasparenza.
1. È fondamentale per comprendere e comunicare il perché dobbiamo compiere determinate attività.
Non si tratta di punto di raccolta dei requisiti o documentazione, ma di un’occasione per poter discutere con tutto il team quale reale obiettivo, bisogno o risultato vogliamo gestire con quell’attività.
Racconta le storie, non scriverle!
Solamente DOPO arrivano tutti i dettagli necessari per poter sviluppare la soluzione che, per comodità, potranno anche essere riportati all’interno dell’elemento così da rendere chiaro cosa ci aspettiamo di ottenere al termine.
2. Non tutti gli elementi sono della stessa tipologia o granularità… l’ordine è fondamentale!
All’interno del Product Backlog possiamo avere diverse tipologie di elementi, ad esempio: User Story, Bug, Spike, Task tecnici o qualsiasi altro tipo di attività necessaria per acquisire informazioni o maggiore conoscenza.
Il principio di fondo è molto semplice: se pensiamo che un elemento sia più importante degli altri starà più in alto nella lista e avrà maggiore priorità, maggiore priorità corrisponde alla probabilità che quell’elemento venga portato in sviluppo prima degli altri. Di conseguenza considerate che maggiore è la distanza dalla sua cima, minore sarà la necessità di avere informazioni di dettaglio.
Ulteriori dettagli approfonditi saranno necessari solamente nel momento in cui quell’elemento potrà passare nello Sprint Backlog.
Va da sé che un attento e frequente aggiornamento delle sue priorità è assolutamente fondamentale per ottimizzare il tempo investito da parte del Team e di tutti gli stakeholder.
3. Il Product Backlog è (o almeno dovrebbe essere) figlio di una Roadmap che a sua volta è (o almeno dovrebbe essere) figlia di una Vision.
Se la Roadmap cambia, le priorità all’interno del Product Backlog devono essere modificate di conseguenza… dal Product Owner!
In pratica stiamo affermando due cose: che si tratta di un essere vivente a tutti gli effetti e che la Vision è sua nonna 😄.
4. Il Product Backlog è uno strumento di condivisione e trasparenza
Detta così sembra una banalità ma questo è letteralmente uno strumento di condivisione e trasparenza nei confronti di tutti gli stakeholder.
Su cosa stiamo lavorando? Quali saranno i prossimi passi? Cosa prevediamo di ottenere alla fine di un certo periodo? Cosa è più o meno importante?
Tutte domande le cui risposte sono contenute nel nostro Product Backlog!
Chi alimenta il Product Backlog?
Comincio subito sfatando un mito: il Product Backlog non viene alimentato esclusivamente dal Product Owner (che comunque, ci tengo a precisare, mantiene la responsabilità di tenerlo costantemente aggiornato e ordinato).
Tutti gli stakeholder potenzialmente sono chiamati a popolare ed arricchire questi elementi ma attenzione, questo non significa che nella lista ci può finire qualsiasi cosa! Ecco alcuni accorgimenti da tenere in considerazione:
- Definisci dei template o standard.
- Impara a dire NO.
Definisci dei template o standard per descrivere i vari elementi
Consiglio vivamente di trovare una modalità strutturata (senza esagerare eh… qb come il sale) per inserire le informazioni all’interno del Product Backlog. Questa modalità aiuta di molto il lavoro del Product Owner nel mantenerlo “vivo”.
Descriviamo un paio di elementi a titolo esemplificativo:
… vogliamo che il nostro prodotto generi delle notifiche per i nostri clienti in tempo reale, così da tenerli costantemente aggiornati. Prova a descrivere un elemento in questo modo:
Come: A quale tipologia di utenti (personas) ci stiamo rivolgendo?
Voglio: Che cosa vogliamo ottenere?
In modo da: Quale problema \ necessità vogliamo risolvere?
… emerso un bug ed il reparto Support lo vuole registrare all’interno del Product Backlog. Chiedi che venga inserito in questo modo:
Contesto: Cosa stai cercando di fare?
Problema verificato: Quale problema hai avuto?
Risultato atteso: Che cosa sarebbe dovuto succedere?
Workaround: Esiste un modo alternativo per ottenere il Risultato atteso?
Impara a dire NO e filtra le richieste che ritieni possano non essere in linea con la direzione del tuo prodotto
Il rischio di accumulare requisiti senza alcun filtro è di avere un backlog pieno di elementi che di fatto non potrebbero non essere mai essere evasi, creando false aspettative verso gli stakeholder.
Imparare a dire di no, eviterà il più possibile che il tuo Product Backlog diventi il “bidone” di qualunque richiesta da parte dei tuoi stakeholder.
Qual è la sua dimensione ideale?
Ovviamente la risposta è: dipende dal contesto in cui ci troviamo.
Detto questo, nella nostra esperienza, un Product Backlog non dovrebbe essere grande più di 5-6 volte la dimensione dello Sprint Backlog. L’esercizio di elencare più di qualche mese di elementi è tipicamente uno spreco di tempo ed energie (le cose cambiano… e cambiano più velocemente di quanto pensiamo!).
Il momento di tagliare la coda per eliminare le cose inessenziali arriva sempre, allora perché non mantenere un Product Backlog leggero, in cui il taglio avviene ex-ante (mentre stai leggendo questo articolo, hai imparato a dire NO?) anziché ex-post?
DEEP – Cosa significa?
DEEP identifica quattro attributi chiave di un Product Backlog:
- D – Detailed appropriately.
- E – Estimated.
- E – Emergent.
- P – Prioritized.
È uno strumento semplice che i Product Owner possono utilizzare per gestirlo efficacemente.
Coniato per la prima volta da Roman Pichler e Mike Cohn, DEEP è semplice, facile da ricordare e può essere eseguito rapidamente.
Detailed appropriately
Gli elementi del nostro Product Backlog dovrebbero contenere informazioni contestuali sufficienti per essere comprese e discusse dal team. Quelli con priorità più alta avranno maggiori dettagli e contesto e saranno chiaramente definite (ma questo, lo abbiamo già imparato sopra).
Estimated
Lo sforzo necessario per ciascun elemento dovrebbe essere stimato con una misura standardizzata concordata dal team (l’approssimazione aumenta man mano ci allontaniamo dalla cima del nostro Product Backlog). Tutti gli elementi dovrebbero avere almeno una stima approssimativa.
Emergent
Poiché un Product Backlog si evolve, è facile aggiungere o rimuovere nuovi elementi quando emergono nuove informazioni. Nulla è definitivo!
Prioritized
Gli elementi nel Product Backlog sono classificati in base al loro valore e agli scopi strategici che servono (Roadmap e Vision vi tornano in mente ora?), con quelli di valore più alti rispetto ad altri.
A noi piace una versione ancora più semplice: DEO (Detailed appropriately, Emergent, Ordered).
Viene rimosso Estimated (davvero è così di valore avere una stima di tutti gli elementi del nostro Product Backlog?) e cambiato Prioritized in Ordered.
To sum up
Al termine di questo articolo, dovremmo essere riusciti a trasmettervi cosa è un Product Backlog, cosa dovrebbe contenere e cosa NON dovrebbe farne parte, qualche sua caratteristica e quali soggetti possono contribuire a renderlo una creatura vivente.
Abbiamo citato diverse volte il ruolo del Product Owner, legato tipicamente a Scrum. Se vogliamo fare un lavoro di astrazione da questo framework, sostituite la parola “Owner con “Manager” (ed ecco che abbiamo il Product Manager) ma il significato non cambia.
Per concludere, la cosa che più ci auguriamo, è che abbia fornito qualche spunto di riflessione su cui meditare, ognuno in modo diverso sulla base del contesto in cui opera. Ricordatevi sempre che la risposta a tutte le vostre domande è… DIPENDE!