Marzo 13, 2023 - di Redazione
Come prioritizzo un backlog di grandi dimensioni?
Come faccio a gestire un backlog troppo grande che si estende all’infinito? Come faccio ad assegnare le giuste priorità?
Sono domande lecite e molto frequenti per un Product Manager o un Product Owner, soprattutto quando le dimensioni del backlog diventano importanti.
Su Product Heroes abbiamo già creato una guida che spiega nel dettaglio che cos’è un Product Backlog e come poterlo “domare” e prioritizzare attraverso il metodo ICE score (che vi consigliamo di leggere se ve lo siete persi).
Quello che invece vi proponiamo oggi, si concentra sulle “tecniche di sopravvivenza” per gestire un backlog “che si estende all’infinito”. Capiremo come affrontare con un approccio incrementale e un mindset di prodotto, le sfide più grandi, anche attraverso un case study.
L’articolo che state per leggere, è una piccola parte del libro Sprint Your Way to Scrum scritto da Valerio Zanini e Bonsy Yelsangi, entrambi Certified Scrum Trainer, con anni di esperienza nella costruzione di prodotti digitali di grande portata.
Il libro risponde a 50 delle più frequenti domande che Valerio e Bonsy hanno raccolto nel corso del tempo, e che hanno deciso di mettere nero su bianco, sotto forma di lista di consigli pratici, per aiutare i team che operano con il framework Scrum e non solo.
La domanda che abbiamo scelto per voi, e sulla quale abbiamo deciso di soffermarci, è quindi dedicata alla gestione del Backlog, e a come affrontare con il giusto mindset, la lista infinita di work item che spesso crea panico e paralizza i team.
Seguiteci!
- Le conseguenze di un backlog troppo grande
- Le possibili cause
- Come gestire il backlog
- Case study: un esempio reale di gestione del backlog
Le conseguenze di un backlog troppo grande
Quando il product backlog si “estende all’infinito”, diventa quasi impossibile gestirlo: è difficile avere una visione d’insieme corretta, ed è difficile assegnare correttamente le priorità a ogni work item presente nella lista.
Assegnare le priorità diventa impossibile
Quando arrivano nuove richieste, dove vanno a finire? In fondo al backlog, nella speranza di vederle prima o poi muovere verso l’alto per essere gestite? Oppure nel bel mezzo del backlog, mescolate con una dozzina di altre cose da fare? O si deve semplicemente interrompere ciò che si sta già facendo, gestire le nuova priorità, e muovere tutto il resto del backlog verso il basso?
Da qualsiasi punto di vista la si guardi, non esiste una soluzione chiara per rispondere alle nuove richieste che arrivano, e continuare a lavorare su quelle che sono già state prese in carico.
Il team si demotiva
Un backlog molto grande, crea anche una sensazione di lavoro infinito, sia per il Product Owner che per il resto del team Scrum. Non importa quanto lavoro si affronta in uno Sprint, o se si riesce ad aumentare la velocity. Quando si guarda al backlog, la quantità di lavoro che rimane ne risente.
Probabilmente, il motivo per cui il backlog di prodotto è così lungo, a prescindere dalla velocity, è che continuano ad arrivare nuove richieste e non si riesce a completare le precedenti. Il team si sente demotivato, in affanno e poco ispirato. Il lavoro viene portato a termine perché “si deve”, ma ciò che viene eseguito non è appagante. Non ci sono insomma momenti per cui vale la pena festeggiare.
Le possibili cause
Un backlog interminabile, può essere la risultante di un enorme progetto che deve essere realizzato. C’è un livello di complessità o semplicemente una grande quantità di funzionalità tale per cui, tutto è documentato nel backlog, come un elenco ricco e puntuale di dettaglio sui requisiti.
A volte è il Product Owner e lo Scrum Team che crea il backlog; a volte viene condiviso da altri stakeholder o dall’organizzazione. Ad esempio, “Dobbiamo sostituire questa applicazione legacy con una piattaforma moderna: ecco l’elenco di tutte le funzionalità che dobbiamo ricreare nella nuova piattaforma per sbarazzarci di quella legacy!“.
Qualcuno passa mesi a documentare tutte le caratteristiche e le feature del nuovo sistema (assicurandosi che non manchi nulla), e questo diventa il backlog del team!
Come gestire il backlog
Ma quindi come gestire un backlog di questa portata?
Riducete e tagliate il backlog, e prendete in considerazione una serie di esperimenti.
Se avete un backlog di dimensioni esagerate, è molto improbabile che riuscirete a fare tutto in pochi mesi. La verità è che il vostro backlog, rappresenta probabilmente anni di duro lavoro. E quando sarete a buon punto, si aggiungerà un altro lungo elenco di attività da fare, che lo riporterà allo stato iniziale.
Il punto è che un backlog con una lista infinita di work item, rappresenta un obiettivo che non sarà mai possibile raggiungere. Quindi è meglio accorciarlo e scartarne una parte.
Ci sono molti modi per poterlo fare. Vi condividerò un paio di tecniche che ho trovato efficaci con i team per fare il trim del Backlog.
1. Prioritizzare il backlog e tagliarlo
Utilizzate il metodo di prioritizzazione MoSCoW (acronimo di Must , Should, Could e will not ), o un’altra tecnica che preferite, per separare le voci del backlog in diversi bucket.
Lavorate con i vostri stakeholder e con il vostro team e chiedete loro di collocare ogni elemento del backlog in uno dei bucket. L’idea qui è di pensare a quali elementi sono davvero importanti, e quali lo sono meno, o che forse lo saranno in futuro.
Decidete un numero massimo di item da assegnare al bucket Must (work item che sono assolutamente prioritari), per limitare il numero di elementi che possono essere inseriti, e obbligate i partecipanti a distribuire gli elementi rimanenti in tutti i bucket disponibili.
Quando tutti gli elementi del Product backlog sono stati assegnati al rispettivo bucket, prendete il “Must” (o comunque il prioritario) e salvatelo. Questo è il vostro nuovo backlog!
Dopo, prendete tutti gli altri bucket e scartateli.
Può sembrare brutale, ma la realtà è che anche se vi concentrate solo sugli elementi che sono “Must”, nel momento in cui li avrete completati tutti, si materializzeranno nuove richieste, che non vi permetteranno comunque di arrivare a lavorare sugli altri bucket, quindi perché preoccuparsi?
OK, se l’idea di eliminarli vi fa stare in ansia, “salvateli” in una scatola nera a 100 miglia di distanza, in modo che non siano più nel vostro backlog, ma sappiate di poterli recuperare, nel caso vi dovessero servire.
2. Lavorare una sola Epica alla volta
Quando ero Product Owner, tenevo un backlog separato di Epiche.
Il mio team lavorava solo su una o due Epiche alla volta: le portavamo a termine e poi selezionavamo le Epiche successive dal Backlog, le suddividevamo in Stories ed eseguivamo il lavoro.
Per gestire il backlog delle epiche, e per preservare la mia sanità mentale, avevo una semplice regola: se un’epica non si fosse “mossa” in 6 mesi, l’avrei cancellata dal backlog.
Questo mi ha aiutato a mantenere il backlog a una dimensione gestibile (ad esempio, è necessario se si usa il metodo WSJF – Weighted Shortest Job First – per stabilire le priorità).
Inoltre, pensavo che se un’epica fosse stata rimossa e fosse stata davvero importante per qualche stakeholder, sarebbero tornati a reclamarla, e io avrei potuto reinserirla nel backlog.
3. Considerare una serie di esperimenti e NON di requisiti
Partiamo dal presupposto che un backlog corposo, spesso rappresenta il lavoro che deve essere fatto per lanciare un nuovo prodotto o un nuovo progetto. E che questo “lavoro” rappresenta “tutte le cose che dobbiamo fare per costruire il prodotto”.
Se tutto ciò che vi è elencato è necessario, allora il backlog rappresenta un documento di requisiti, formulato in modo diverso, creato e pianificato in anticipo, e con una scarsa validazione. Si può costruire anche in modo iterativo utilizzando gli Sprint, ma tutto il lavoro è definito up front.
Non c’è scoperta, né convalida, né iterazione sul backlog stesso. Tutto deve essere fatto e si sceglie semplicemente di eseguire il lavoro in Sprint.
Invito sempre le persone con cui lavoro a cambiare la loro interpretazione e a pensare al backlog come “le possibili cose che potremmo fare per costruire il prodotto”. In questo modo si sposta l’interpretazione da “requisito” (qualcosa di necessario, qualcosa che dobbiamo fare per forza) ad “esperimento”.
Un esperimento è qualcosa che si può considerare di fare, perché si pensa che possa essere utile, ma non si è sicuri che generi un impatto. Quindi, si può pensare di costruire una piccola parte di una funzionalità, testarla con gli utenti, e poi continuare a costruirla se è davvero valida. Se non lo è, scartarla e passare all’esperimento successivo.
Cambio di Mindset: da requisito a esperimento
Si tratta di un cambiamento di mentalità molto importante per i Product Owner che devono gestire i loro backlog.
Quando è presente questa mentalità, il backlog non è più un archivio di tutte le possibili cose da fare sul prodotto. Si tratta piuttosto di un backlog di esperimenti, di cose che possiamo fare per convalidare le nostre idee e, in caso di successo, costruire la funzionalità che abbiamo convalidato.
Questa mentalità favorisce la centralità dell’utente e la convalida rapida, riducendo il rischio di costruire la soluzione sbagliata e concentrando il lavoro del team su ciò che è veramente prezioso, piuttosto che costruire tutto.
Case study: un esempio reale di gestione del backlog
L’esempio che vi faccio è un esempio reale di un sistema di auto a guida autonoma.
L’azienda crea i sensori e il software d’intelligenza artificiale per il sistema di guida autonoma, e lo vende alle diverse case automobilistiche che a loro volta lo installano sulle loro auto.
Finora, l’azienda ha realizzato una versione del prodotto in grado di guidare autonomamente un’auto in condizioni stradali “limitate”, e fino a 40 miglia orarie (64 km/h). Ha anche collaborato con alcune case automobilistiche per testare il sistema e raccogliere feedback.
Di recente, le case automobilistiche hanno richiesto che il sistema diventi completamente autonomo e con una velocità massima di 130 km/h. Ciò consentirà al sistema di guidare in autostrada e ovunque senza alcuna assistenza da parte del conducente.
Un primo approccio: specificare tutti i dettagli up front
Dal punto di vista del team di prodotto, lo sviluppo di questo prodotto inizia con lo specificare l’elenco completo delle condizioni e dei diversi comportamenti che il sistema dovrà gestire.
Ad esempio quando c’è un’auto davanti; quando non c’è nessun’altra auto; quando la strada curva; quando la strada è dissestata; quando piove, nevica o c’è il sole; quando un’altra auto passa sulla sinistra e poi taglia improvvisamente davanti; o quando un essere umano, un animale o un altro piccolo veicolo attraversa la strada davanti.
L’elenco si allunga rapidamente, se si pensa a tutto ciò che può accadere durante la guida, e cresce esponenzialmente se si considera la guida ad alta velocità. Il sistema deve soddisfare tutte queste condizioni, altrimenti le case automobilistiche non potranno installarlo in sicurezza sulle auto.
È ancora più complesso, perché noi esseri umani abbiamo la capacità di adattarci a situazioni nuove o inaspettate e di decidere rapidamente come gestirle in base alla nostra formazione ed esperienza.
Un algoritmo informatico invece, ha bisogno di istruzioni chiare su come deve elaborare una situazione, e il numero di combinazioni possibili negli scenari di guida reali può essere infinito. Pertanto, il sistema deve sviluppare un livello sofisticato di intelligenza artificiale utilizzando una serie di modelli e comportamenti noti e, da lì, sviluppare la capacità di prendere decisioni in situazioni che non corrispondono a una serie di criteri precedentemente noti.
Il backlog diventa incredibilmente lungo, e il team di prodotto fatica a dare un senso a tutto questo e a decidere da dove partire. Hanno davanti a sé anni di lavoro, prima di avere qualcosa che le case automobilistiche potranno testare.
Un secondo approccio: il processo incrementale
Ho aiutato così il team ad affrontare il lavoro da un punto di vista diverso.
Piuttosto che fare un elenco di tutti i possibili casi d’uso e condizioni e poi costruirli, cosa succederebbe se potessero identificare un caso d’uso semplice e valido, costruirlo e convalidarlo con i loro utenti?
In base a quanto appreso, potrebbero decidere quale dovrebbe essere il caso d’uso successivo e continuare a costruire in modo incrementale.
Il team ha scelto come caso d’uso iniziale la capacità di un’auto di guidare autonomamente su un’autostrada senza altre auto o ostacoli sul percorso, durante una giornata di sole in piena luce, viaggiando a velocità fino a 130 km/h e senza cambi di corsia.
Anche nella sua semplicità, la soluzione di questo caso d’uso non è stata banale e ha richiesto lo sviluppo di una solida base per il funzionamento del sistema a quella velocità. La domanda a cui il team voleva rispondere era: “Possiamo costruirlo e come lo costruiamo?”.
Il team si rendeva conto che era prematuro rilasciare il prodotto sul mercato. Ma non era questo il punto.
L’obiettivo era costruire un sistema in grado di soddisfare un caso d’uso base fondamentale – di fatto il più semplice e controllabile di tutti – e dimostrare le tecnologie necessarie per soddisfarlo. Imparare da questo, e poi lavorare sul caso d’uso successivo (ad esempio, guidare su un’autostrada e aggiungere altre auto, o guidare su un’autostrada con condizioni meteorologiche non perfette).
Convalidare ogni caso d’uso nel modo più rapido possibile, valutare le prestazioni del sistema, ottenere il feedback degli utenti e solo dopo aver appreso, aggiungere il caso d’uso successivo.
Questo modo di suddividere il backlog in una serie di esperimenti per una rapida convalida della tecnologia e dell’applicazione reale, ha aiutato il team a ottenere un feedback dai utenti molto prima di quanto sarebbe stato possibile se avessero costruito tutto, e ha aiutato il team a migliorare notevolmente la propria produttività.
Se l’articolo vi è piaciuto e avete delle domande particolari da farci, o da fare a Valerio e Bonsy, scrivetelo nei commenti qui sotto.
Per rimanere aggiornato sui prossimi contenuti, iscriviti alla nostra Newsletter 📩
Leggi di più sulle tecniche di Prioritizzazione
