3 Esempi di Product Backlog Fatti Bene (+ Cosa Non Fare)
Ti è mai capitato di guardare il tuo backlog e voler eliminare tutto per ricominciare da capo? Bene, ho provato questa sensazione più di una volta, poiché costruire e mantenere i product backlog non è affatto facile. Ma, per mostrarti come gestire i backlog nel modo giusto e ispirarti a fare ordine nel tuo, lascia che ti condivida quattro eccezionali esempi di product backlog.
Cosa È il Product Backlog in Agile e Scrum?
Il product backlog è un documento vivo che contiene tutti gli elementi su cui il team di prodotto, lo scrum master e il team di ingegneria pianificano di lavorare per costruire il loro prodotto.
Include tutto ciò di cui hai bisogno per costruire e mantenere il tuo prodotto, tra cui nuove funzionalità, attività di debito tecnico, miglioramenti dei processi tecnici dal tuo ultimo retrospective, compiti di automazione QA e altro ancora.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
La caratteristica principale di un product backlog è che si tratta di un elenco prioritizzato in cui gli elementi in cima hanno la priorità più alta e il team dovrebbe occuparsene per primi quando pianifica gli sprint (o quando ha spazio libero sulla propria kanban board).
Product Backlog vs Sprint Backlog vs Product Roadmap: Qual è la Differenza?
Nella gestione dei progetti Agile e nella metodologia scrum in particolare, il product backlog non è l’unica lista di elementi che il product owner crea per il tuo team di sviluppo. Ci sono anche lo sprint backlog e la product roadmap. Ma qual è la loro differenza? Vediamolo insieme.
Sprint Backlog: Questa è una sottosezione del backlog più grande e contiene solo gli elementi che il team scrum ha incluso nel prossimo sprint o in un altro tipo di iterazione come risultato di una sessione di pianificazione dello sprint. Gli elementi qui sono di solito ben curati e includono gli story point.
Product Roadmap: Questo è un documento di alto livello che mostra le funzionalità principali e le milestone per il prodotto. A differenza del backlog, che è più tattico e contiene la descrizione delle funzionalità, la product roadmap è strategica e ha lo scopo di mostrare ai membri del team e agli stakeholder la direzione che prenderà il prodotto e quali sono le aree di massima priorità.
Ora che tu e i concetti chiave siete stati adeguatamente introdotti, lasciami entrare subito nel dettaglio su come gestire il tuo product backlog (e come, ehm, non farlo).
Come NON Gestirlo: Ecco Un Esempio Terribile di Product Backlog
Capire gli antipattern nella creazione e gestione dei product backlog è probabilmente tanto importante quanto imparare le best practice. Il motivo è che, se non sai cosa sia un antipattern, rischi di inserirlo nel tuo backlog e pensare che si tratti di qualcosa di normale e ordinario.
Per esaminare alcune delle pratiche che possono ridurre significativamente la qualità del tuo backlog, osserviamo l’esempio qui sotto.
Tornando all’esempio. Prenditi il tempo necessario per esaminarlo con attenzione.
Sembra davvero orribile, vero? In effetti, guardando questo backlog, la maggior parte di noi proverà due emozioni:
- Disgusto per la confusione degli elementi presenti in questo backlog.
- Senso di colpa, perché ammettiamolo, tutti noi abbiamo avuto un backlog che assomigliava a questo (anch’io, ovviamente).
Ora analizziamo i problemi presenti in questo backlog.
Sovraccarico di Elementi nel Product Backlog
Hai notato che c’erano 665 attività in questo backlog? Bene, il backlog più grande che ho avuto il “piacere” di gestire aveva più di 2.500 elementi.
Il problema di un backlog sovraccarico è che quasi sicuramente non riuscirai a ricordare cosa sia ogni elemento e perché lo hai posizionato in una certa posizione/priorità nel tuo backlog. Non avendo idea di cosa siano questi task, difficilmente li porterai al prossimo refinement, discuterai i dettagli o li includerai nello sprint successivo.
Così ti ritrovi con un enorme pasticcio ingestibile che continua ad accumularsi all'infinito.
Pianificazione impropria delle priorità del backlog
Un altro problema che potresti aver notato in questa lista di backlog è la presenza di elementi di lavoro con priorità “Più bassa” e “Bassa” posizionati in cima—sopra elementi con priorità “Massima”.
Questo rappresenta il caso tipico in cui il backlog non è correttamente prioritizzato. Le ragioni possono essere molte, ma la più probabile è che hai declassato un elemento ad “Alta” priorità abbassandolo di posizione nella lista senza però modificare il campo della priorità.
Mancanza di dettaglio
Hai notato l’elemento che recita “Voglio un'integrazione senza soluzione di continuità con tutte le piattaforme di social media”? LOL. Non è nemmeno una vera user story, considerando l'enorme portata a cui mira. La portata è talmente vasta che, in pratica, dovresti avere diverse epic che la coprono, ognuna contenente le storie di una singola piattaforma social.
Oltre all’ampiezza dello scopo, il problema di questo elemento (in realtà, di ogni elemento in questo backlog) è la sua vaghezza. Le user story dovrebbero descrivere una specifica esperienza e azione dell’utente.
Immagina di portare questa storia alla riunione di backlog grooming con il tuo team Agile. Ti troveresti subissato di domande su quasi ogni aspetto della storia.
“Cosa intendi per senza soluzione di continuità?” “Come dovrebbe essere l’integrazione?” “Con quali piattaforme social dobbiamo integrarci?!”
“Voglio tutto, e subito”
Un altro campanello d’allarme che potresti aver notato nel backlog era che il 70% degli elementi aveva priorità “Massima”. È una situazione tipica se ti basi unicamente sulle opinioni degli stakeholder per assegnare le priorità (e ogni stakeholder considera importanti i suoi elementi) senza cercare di valutarli oggettivamente e confrontare la loro importanza rispetto agli altri elementi nella lista.
Ora che abbiamo definito com’è fatto un cattivo backlog, sistemiamolo e vediamo quattro buoni esempi di backlog... così potrai rendere il tuo backlog davvero efficace.
3 esempi di backlog fatti bene
Prima di mostrarti questi esempi, voglio precisare che non esiste una sola maniera corretta di creare un backlog eccellente. L’aspetto che avrà dipenderà dalla natura del tuo prodotto, dalla sua maturità, dalla dimensione della tua azienda o team, ecc.
In realtà, un ottimo backlog è quello che riesce a portare chiarezza e allineamento tra tutti riguardo l’ambito attuale e futuro del tuo prodotto.
Tuttavia, esistono modi generici di gestire il backlog che ti aiuteranno a renderlo più organizzato e facile da usare per tutti. Ognuno degli esempi qui sotto rappresenta una di queste best practice.
Esempio #1: Un backlog suddiviso in sezioni
Quasi mai è accettabile avere un backlog con centinaia o migliaia di elementi. Tuttavia, avere circa 100 elementi è solitamente piuttosto comune e normale. Ma anche con un centinaio di elementi, è facile dimenticare di cosa si occupa ciascuno o lasciarli inutilizzati a lungo senza inserirli nei prossimi sprint.
Per rendere il backlog più organizzato, puoi considerare di suddividerlo in sezioni.
Alcuni product manager preferiscono usare le sezioni per raggruppare gli elementi in base alle aree di interesse o alle milestone. Personalmente preferisco usare tag come Versione, Epic e Componente nei task per questo scopo, e suddividere il backlog in sezioni secondo l’ambito dei prossimi sprint.
Questo è un ottimo modo per assegnare uno sprint (o almeno una stima di tempistiche) alla vasta maggioranza degli elementi del backlog e assicurarsi che nessun task venga trascurato.
Un altro modo comune di gestire il backlog con le sezioni è raggruppare gli elementi in base al loro stato di affinamento/flusso di lavoro (questo è qualcosa che l’Intelligenza Artificiale nella gestione del backlog può aiutare a fare). In questo caso, ottimizzi il tuo processo con le seguenti sezioni:
- Sprint attuale
- Pronto per la pianificazione
- Pronto per il grooming
- Backlog
Quello che fai in questo caso è lavorare sull’aggiunta di requisiti di prodotto e descrizioni per gli elementi nel backlog. Quando i requisiti sono pronti, li sposti nella sezione “Pronto per il grooming”, che funge da ambito per il prossimo incontro di raffinamento.
Dopo aver raffinato un elemento, lo sposti nella sezione “Pronto per la pianificazione”, indicando che è pronto e il team può includerlo nello sprint successivo.
Esempio n. 2: Un backlog con componenti, epic e versioni collocati correttamente
Segmentare il backlog lo rende sicuramente più pulito e organizzato. Ma il limite dell’uso esclusivo della segmentazione è che puoi organizzare il backlog secondo un solo criterio (ad esempio, gli sprint, lo stato di grooming, ecc.).
Per fortuna, i moderni strumenti per backlog di prodotto ti offrono una gamma più ampia di opzioni per organizzare la lista delle cose da fare nello sviluppo prodotto in base a criteri multipli. Guarda che meraviglia di backlog.
Non sembra forse ben organizzato e piacevole da vedere? In questo caso specifico, abbiamo sfruttato le seguenti funzionalità per rendere il nostro backlog più gestibile:
Componenti
Questo campo/caratteristica abitualmente descrive l’area del prodotto dove desideri aggiungere la funzione in questione. Nell’esempio sopra, i componenti sono i prodotti separati che compongono Grammarly.
Un altro modo frequente di usare i componenti è organizzare storie/attività in base alla tecnologia richiesta per creare la funzionalità. Per le applicazioni web, ad esempio, puoi avere componenti Frontend/Backend, che ti aiutano a organizzare il lavoro e le dipendenze tra ingegneri specializzati nello sviluppo lato client o lato server.
Versioni/rilasci
Con questa caratteristica, documenti tutte le funzionalità e le correzioni di bug che il tuo team scrum rilascerà con una certa versione del prodotto. Il tracciamento delle versioni nel backlog porta due vantaggi molto preziosi.
- Ti aiuta a pianificare i tuoi sprint e i tuoi rilasci. Ad esempio, se pianifichi un rilascio fra 2 settimane, durante la riunione di pianificazione dovresti assicurarti di includere tutte le attività previste per quella versione di rilascio nello sprint.
- Ti permette di documentare tutto ciò che il team ha included in una certa versione e di risalire facilmente ai problemi quando accade qualcosa in produzione.
Ad esempio, immagina che le persone inizino a ricevere errori Captcha durante il flusso di registrazione nell’ultima versione 1.3.2. Cercando il task attraverso il quale il team ha modificato le impostazioni del captcha, scopri che appartiene alla versione 1.3.1. Questo significa che dovrai fare un rollback alla versione 1.3.0 oppure effettuare un hotfix.
Epic
Bene, non penso ci sia bisogno di spiegare che cos’è un epic e quali vantaggi porta il suo utilizzo. Se però vuoi approfondire le migliori pratiche e tutti i dettagli riguardo agli epic, dai un’occhiata alla nostra guida agli epic (gioco di parole voluto!) sull’argomento.
Esempio n. 3: Un backlog con il giusto livello di dettaglio per ogni sezione
Questa è una best practice che potresti aver incontrato in molti libri e contributi teorici su Agile e product management. Sebbene più si acquisisce esperienza più si diventa scettici verso i concetti teorici, questa pratica risulta effettivamente utile.
L’idea è quindi che gli elementi in cima abbiano molti dettagli e che tu li abbia già sottoposti almeno una volta ad un refinement del backlog di prodotto. Gli elementi in fondo al backlog, invece, dovrebbero avere pochi dettagli, poiché è molto probabile che tu impari qualcosa di nuovo sul tuo prodotto e sui tuoi utenti finali e che questo elemento diventi obsoleto.
Significa che se l’elemento in cima al backlog si presenta così (o addirittura più dettagliato di così):
Le storie che si trovano in fondo al tuo backlog dovrebbero avere molti meno dettagli e apparire così:
Qualunque storia o iniziativa tu abbia a metà del backlog avrà un livello medio di dettaglio.
Esempio n. 4: So che è ovvio, ma… un backlog pulito
So che non è facile mantenere il backlog pulito. Ci sono passato molte volte e so che sembra un compito noioso. Tuttavia, non rivedere tutto il tuo backlog e non ricordarsi di eliminare gli elementi obsoleti sono fattori determinanti per la qualità del backlog.
Non è sempre facile eliminare elementi dal backlog. Ci sono funzionalità molto interessanti là fuori che speri di realizzare un giorno (principalmente "nice-to-have") e a volte non vuoi davvero sbarazzartene. Ma, ad un certo punto, ammettiamolo, sai che non la realizzerai mai. E anche se dovessi farlo, significherebbe che hai esaurito le caratteristiche ad alta priorità, il che in generale non è un buon segnale.
A volte sono gli stakeholder ad aver inserito questi elementi obsoleti nel backlog. Prima di eliminarli, provi a chiedere se la loro richiesta è ancora valida e la risposta è quasi sempre sì. Beh, se la richiesta ha più di 6 mesi e se ne erano già dimenticati, convincili semplicemente che non è qualcosa di urgente (se lo fosse stato, avrebbero seguito la cosa più volte) ed eliminala.
Un backlog eccellente è quello che funziona meglio per te
Se tenessi conto di tutte le buone pratiche qui descritte, avresti un backlog eccellente? Beh, sicuramente aiuterebbero, ma non garantirebbero la perfezione.
Non dimenticare che lo scopo del backlog è essere l'unica fonte di verità per tutti. Quindi, oltre a queste best practice, devi considerare i bisogni e lo stile di lavoro del tuo team e degli stakeholder e costruire il backlog in modo che li aiuti a rimanere tutti allineati.
Questa guida su come costruire un backlog efficace fa parte di una serie più ampia dedicata all’Agile. Iscriviti alla nostra newsletter per altre guide e approfondimenti come questo, direttamente ogni due settimane nella tua casella email!
