Elenco delle attività del prodotto e del ciclo di lavoro: differenze principali

I backlog sono la spina dorsale dei flussi di lavoro Agile e guidano i team dalle idee all’esecuzione. Tuttavia, un errore comune consiste nel non distinguere tra backlog di prodotto e backlog di sprint: un errore che può portare a priorità disallineate, sprint inefficienti e team frustrati.

Sebbene molti di noi abbiano esperienza nell’utilizzo di software per la gestione dei backlog, usare in modo improprio questi due strumenti distinti può causare più confusione che chiarezza.

Quindi, come possiamo assicurarci che i nostri backlog lavorino a nostro favore e non contro di noi? Comprendere i loro ruoli specifici non riguarda solo le definizioni: significa risolvere i problemi comuni dei flussi di lavoro e ottimizzare la collaborazione del team. Analizziamo le loro differenze ed esploriamo come utilizzarli in modo efficace.

Che cos’è un backlog di prodotto?

Una spiegazione breve e semplificata di che cos’è un backlog di prodotto: comprende tutte le funzionalità e le attività su cui tu e il tuo team di sviluppo prevedete di lavorare.

Per una definizione più strutturata, facciamo riferimento ad Atlassian.

Avrai notato che gli esperti di Atlassian hanno sottolineato due concetti importanti nella definizione del backlog.

1. È organizzato per priorità.

Creare un semplice elenco di elementi da sviluppare porterà o a un enorme caos o a un prodotto incapace di risolvere adeguatamente i problemi degli utenti. Pertanto, un elenco di funzionalità non è davvero un backlog di prodotto finché non viene definita la priorità.

2. È una derivazione della roadmap.

Ho visto moltissimi backlog che erano semplicemente il risultato della condivisione delle idee sulle funzionalità da parte di tutti e del loro inserimento nel backlog. Il risultato è un caos e un prodotto che sembra il mostro di Frankenstein. Se vuoi che gli elementi del backlog contribuiscano al raggiungimento di uno specifico obiettivo di prodotto o aziendale, devi costruirlo sulla base della tua roadmap e della visione del prodotto.

Lo scopo principale di avere un backlog è creare un’unica fonte di verità per tutti i membri dell’azienda. Dovrebbe esserci sempre un solo backlog e tutti dovrebbero farvi riferimento quando decidono cosa fare dopo.

Oltre a questo, il backlog di prodotto è anche un ottimo strumento per facilitare la definizione delle priorità per te e per i tuoi stakeholder, poiché contiene tutto ciò che devi fare sotto forma di un unico elenco.

Che cosa dovrebbe includere un backlog?

Supponendo che tu stia utilizzando uno dei framework Agile, il tuo backlog di prodotto sarà composto dai seguenti elementi:

• Epic: funzionalità di grandi dimensioni che aiutano a raggiungere obiettivi specifici del prodotto, come aumentare la conversione, risolvere un problema specifico degli utenti o migliorare la loro esperienza all’interno del prodotto. La funzione di commento di Google Docs ne è un esempio. In genere, le epic sono composte da “sottofunzionalità” più piccole chiamate user story.
• User story: piccole funzionalità o elementi di una funzionalità utilizzabili dai tuoi clienti. Nell’esempio della funzionalità di Google Docs riportato sopra, “menzionare qualcuno in un commento” o “risolvere un commento” sarebbero esempi tipici di user story appartenenti a quell’epic.
• Attività tecniche: attività che il tuo team di sviluppo deve svolgere e che non sono correlate alle funzionalità presenti nel backlog. Alcuni esempi sono la configurazione di un database di backup, il refactoring di un microservizio o l’ottimizzazione della velocità delle query.
• Bug: non è un vero backlog se non contiene bug. Per quanto bene tu possa sviluppare e testare le tue funzionalità, questi piccoli parassiti finiranno sempre per comparire. Pertanto, devi conservarli, monitorarli e gestirli in qualche modo. La prassi migliore consiste nell’archiviarli nel backlog e stabilirne la priorità proprio come per qualsiasi altro elemento del backlog.

Ecco come apparirà un tipico backlog di prodotto:

P.S. Leggi il nostro articolo su 3 esempi di backlog di prodotto realizzati correttamente se cerchi ulteriori indicazioni.

Ora comprendiamo il ruolo del responsabile di prodotto nella gestione del backlog.

Chi è responsabile della gestione del backlog?

In breve: il responsabile di prodotto è il dio del backlog. Detiene le chiavi di ciò che viene costruito, dell’ordine in cui viene realizzato e del motivo per cui lo si fa. Il backlog è il suo dominio ed è in ultima analisi responsabile di assicurarsi che rimanga allineato con la visione del prodotto, le esigenze degli utenti e gli obiettivi aziendali.

Questo non significa che il PM sia l’unico a occuparsi del backlog. Ingegneri, designer e altri membri del team possono suggerire o persino aggiungere elementi, ma ogni modifica dovrebbe avvenire sotto la supervisione del PM. Dopotutto, un backlog caotico porta a un prodotto caotico.

Le principali responsabilità di un PM riguardo al backlog includono:

• Stabilire le priorità del backlog – Assicurarsi che il lavoro più prezioso e d’impatto venga affrontato per primo.
• Affinarlo con il team – Esaminare, aggiornare e suddividere regolarmente gli elementi per mantenere il lavoro chiaro e attuabile.
• Comunicare le priorità e le modifiche del backlog – Mantenere informati gli stakeholder, così da evitare sorprese.

Poiché il backlog è un documento dinamico, si evolve costantemente. Emergono nuove idee, le priorità cambiano e alcune funzionalità vengono eliminate del tutto. Questa fluidità è un principio fondamentale dell’Agile: il backlog dovrebbe riflettere la realtà più recente, non un piano rigido e obsoleto.

Un backlog ben gestito non è solo un elenco di attività; è uno strumento strategico che aiuta i team a costruire il prodotto giusto al momento giusto. E al centro di tutto? Il responsabile di prodotto, che detiene le chiavi.

Creare e gestire un backlog di prodotto: guida introduttiva

Inizi a creare la versione iniziale del backlog non appena la roadmap del prodotto è completa. Di solito prendi tutte le funzionalità significative e le parti di lavoro dalla roadmap e le trasformi in epiche nel backlog.

Successivamente, inizi a sviluppare i documenti dei requisiti di prodotto per ciascuna di esse e crei le epiche sulla base della scomposizione delle funzionalità all’interno del tuo PRD.

Tuttavia, come naturale conseguenza dello sviluppo del prodotto, finirai per modificare costantemente queste epiche, aggiungere storie indipendenti e bug, fino a ottenere un backlog simile a quello con cui la maggior parte di noi lavora. Insomma, un backlog disordinato.

Ma è abbastanza facile mantenere il backlog se:

• Organizzi regolarmente sessioni di affinamento del backlog.
• Dedichi del tempo nel prossimo sprint alla correzione massiva dei bug e alla loro rimozione dal backlog.
• Non permetti a tutti di aggiungere le proprie idee al backlog senza prima consultarti.
• Stabilisci costantemente le priorità del backlog.
• Utilizzi la mappatura delle storie utente per avere una visione chiara di ciò che deve essere fatto.

Per quanto riguarda l’ultimo punto, ecco due principali tecniche di definizione delle priorità che ti suggerirei di utilizzare sulla base della mia lunga esperienza nel provarne una dozzina.

MoSCoW

Si tratta di una tecnica abbastanza semplice che raggruppa gli elementi del backlog in queste quattro categorie:

• Indispensabile: Quando la funzionalità fa parte di un percorso utente fondamentale e non puoi risolvere i problemi degli utenti senza di essa. Per esempio, le playlist di Spotify sono indispensabili.
• Importante: Un miglioramento significativo del percorso utente. Nel caso di Spotify, sarebbe la possibilità di cercare playlist già create in base al proprio stato d’animo o all’attività svolta.
• Utile: Qualcosa che piace all’utente, ma la cui assenza non rappresenta un ostacolo decisivo. Spotify potrebbe consentire di cambiare brano tramite gesti invece che con pulsanti.
• Da non includere: Funzionalità o iniziative che tu, i tuoi stakeholder o il tuo team avete considerato inutili durante le riunioni di affinamento o di definizione delle priorità.

Come puoi vedere, MoSCoW è una tecnica abbastanza semplice. Ed è proprio uno dei motivi per cui mi piace usarla: è molto facile da spiegare a tutti i presenti e convincerli a utilizzarla a loro volta quando devono selezionare le attività a bassa o alta priorità dall’elenco degli elementi su cui stanno lavorando.

Kano

Un’altra tecnica semplice che consente di osservare le funzionalità in questione dalla prospettiva delle esigenze degli utenti. In questo caso, raggruppi le funzionalità in queste categorie:

• Esigenze di base: La loro assenza è un motivo sufficiente per rifiutare il prodotto o servizio. In una camera d’albergo, sarebbe la presenza di lenzuola pulite sul letto.
• Esigenze di prestazione: Funzionalità la cui quantità o presenza aumenta direttamente la soddisfazione dell’utente. Si tratta dell’arredamento della camera d’albergo o della presenza di servizi di lavanderia o colazione.
• Esigenze di entusiasmo: La loro assenza non ridurrà la soddisfazione, ma la loro presenza la aumenterà certamente. È il caso del grazioso origami a forma di cigno realizzato con gli asciugamani sul letto della camera d’albergo.

Ecco un grafico che illustra la relazione tra questi tipi di funzionalità e la soddisfazione dell’utente secondo il modello Kano.

In sintesi, il backlog di prodotto è l’elenco delle attività da svolgere del team, che il product manager (o il team di prodotto) crea e gestisce utilizzando un’ampia varietà di strumenti e tecniche per la gestione del backlog.

Che cos’è un backlog di sprint?

Ora che la natura del backlog di prodotto ci è chiara, cerchiamo di capire in cosa consiste il backlog di sprint (suggerimento: non ha nulla a che fare con l’esercizio fisico).

Scrum.org definisce il backlog di sprint come il sottoinsieme del backlog di prodotto che il team Scrum ha scelto di completare durante lo sprint successivo. Nel framework Scrum, è uno degli artefatti Scrum fondamentali con cui lavora l’intero team.

Come suggerisce la definizione, lo scopo principale del backlog di sprint è definire chiaramente l’ambito del lavoro su cui il team deve concentrarsi durante lo sprint.

Il processo di creazione del backlog di sprint avviene solitamente durante la riunione di pianificazione dello sprint. In questa sede, in genere si svolgono le seguenti attività:

1. Il product manager definisce l’obiettivo dello sprint.
2. Il team inizia a selezionare un elenco realizzabile di risultati finali che possano aiutarlo a raggiungere questo obiettivo.
3. Il team suddivide le storie in attività tecniche e le stima.
4. Esamina la propria capacità e la velocità degli sprint precedenti per verificare che il backlog di sprint sia realizzabile.

A differenza del backlog di prodotto, di cui il PM è l’unico responsabile, la responsabilità di creare e gestire il backlog di sprint spetta al team Scrum. Poiché sono le persone che svolgono le attività necessarie per realizzare le funzionalità, sono le più adatte a decidere le dimensioni e l’ambito del backlog di sprint.

A differenza di molti altri artefatti Scrum, che alcuni team potrebbero decidere di ignorare (ed è perfettamente accettabile: si adotta Scrum per adattarlo al proprio team, non il contrario), il backlog di sprint sembra essere quello utilizzato quasi da tutti. Ci sono buone ragioni. In particolare, il backlog di sprint offre:

• Chiarezza dell’ambito: Il team comprende correttamente il lavoro che dovrà svolgere durante la prossima iterazione.
• Maggiore concentrazione: Con un ambito di lavoro chiaro e uno Scrum master che contrasta i tentativi di chiunque di aggiungere nuove attività allo sprint, il team non deve concentrarsi su altro se non sugli elementi presenti nel backlog di sprint.
• Migliore monitoraggio dei progressi: Poiché non entrano né escono elementi dal backlog di sprint, è abbastanza semplice capire quanto il team stia procedendo verso l’obiettivo dello sprint.

Per quanto riguarda il terzo punto, la maggior parte degli strumenti Agile dispone di strumenti integrati per la reportistica degli sprint, che monitorano automaticamente i progressi del team. Uno dei report più diffusi a questo scopo è il grafico burndown.

Questo grafico è composto da due linee con andamento discendente. La linea grigia rappresenta l’andamento ideale ipotetico del team. La linea rossa, invece, rappresenta l’avanzamento effettivo. Jira (lo strumento mostrato nella schermata) misura queste linee in base al numero totale di story point che il team deve ancora completare. Pertanto, quando qualcuno chiude un’attività, la linea rossa scende di una quantità pari agli story point stimati per quell’attività.

Creazione e gestione di un backlog di sprint

Il processo di creazione di un backlog dello sprint inizia con un backlog del prodotto che non è ancora stato perfezionato. I responsabili di prodotto organizzano regolarmente riunioni di perfezionamento del backlog (note anche come riunioni di grooming), durante le quali il team:

• Pone domande al PM sul design e sui requisiti, per avere una comprensione chiara di ciò che il team di prodotto si aspetta che venga realizzato.
• Mette in discussione alcuni punti dei requisiti se la loro realizzazione richiede troppo tempo o comporta difficoltà tecniche.
• Assegna la responsabilità di ogni elemento del backlog al membro del team che ritiene più adatto per quella particolare attività.
• Stima le dimensioni dell'attività o della storia utilizzando una delle tecniche più diffuse, come i numeri di Fibonacci abbinati al planning poker.

Supponendo che il team abbia perfezionato un numero sufficiente di attività per la prossima iterazione, organizzerà una riunione di pianificazione dello sprint, durante la quale si impegnerà a realizzare una certa quantità di attività dal backlog del prodotto. Nel momento in cui il team assume questo impegno e inizia lo sprint, questo gruppo di attività diventa il backlog dello sprint.

Per gestire il backlog dello sprint, la metodologia Agile mette a disposizione diversi strumenti, tra cui:

• Riunioni giornaliere in piedi, durante le quali ogni membro del team mostra i propri progressi al team e segnala eventuali impedimenti che ne rallentano il lavoro.
• Grafici burn-up e burn-down che visualizzano i progressi complessivi del team.
• Riunioni dimostrative alla fine dello sprint, durante le quali il team presenta i risultati del proprio lavoro al team di prodotto e riceve feedback utili e concreti sul design e sulle funzionalità che ha realizzato.

Infine, ci sono le riunioni retrospettive. Non aiutano direttamente a gestire il backlog dello sprint, ma consentono di discutere i processi che miglioreranno la qualità e l'efficienza della sua gestione.

Differenze principali tra backlog del prodotto e backlog dello sprint

Per comprendere meglio le differenze tra questi concetti apparentemente simili, vorrei fornire una panoramica comparativa di come si distinguono, per poi spiegare ogni elemento in maggiore dettaglio.

Sebbene la panoramica sia di per sé sufficiente a spiegare in cosa differiscono, potresti avere ancora domande su aspetti specifici. Esaminiamoli quindi uno alla volta.

Intervallo di tempo: I backlog del prodotto rappresentano il piano a medio e lungo termine, poiché riflettono la roadmap e la visione del prodotto. Di conseguenza, l'orizzonte di pianificazione può variare da diversi sprint fino a un paio d'anni.

I backlog dello sprint, d'altra parte, hanno un intervallo di tempo molto breve, poiché rappresentano gli elementi che il team intende consegnare nel prossimo sprint (che di solito dura da 1 a 4 settimane).

Responsabilità: Come abbiamo già detto, la persona in ultima istanza responsabile del backlog del prodotto appartiene al team di prodotto (di solito è il responsabile di prodotto assegnato a quel team). Il team Scrum può contribuire al backlog, ma può farlo solo tramite il PM.

La situazione è diversa per il backlog dello sprint. L'unico modo in cui un PM può influenzarlo è definendo l'obiettivo dello sprint. A parte questo, è il team Scrum ad avere l'autorità di crearlo e gestirlo.

Livello di dettaglio: Poiché gli elementi di un backlog del prodotto possono rappresentare il lavoro di diversi trimestri o persino anni, non è realistico che il PM descriva ogni elemento in dettaglio. Anzi, lo sconsiglio vivamente, poiché c'è sempre la possibilità che tu finisca per eliminare molte funzionalità e sarebbe uno spreco di tempo averle descritte meticolosamente.

Di solito, gli elementi con la priorità più alta presentano un livello di dettaglio elevato, mentre per tutto il resto è sufficiente una descrizione sommaria.

Per entrare nel backlog dello sprint, invece, le storie devono includere tutti i dettagli disponibili. In caso contrario, il team Scrum rifiuterà di implementarle se non avrà una comprensione chiara di ciò che ci si aspetta da esso.

Scopo: Il backlog del prodotto è l'“intermediario” tra piani strategici molto vaghi e dettagli tecnici di implementazione molto specifici. Funge da strumento per esprimere i piani strategici sotto forma di elenco di attività da svolgere.

I backlog dello sprint, d'altra parte, hanno una natura altamente tattica e mirano a fornire al team un piano d'azione e un ambito chiari per il breve termine.

Flessibilità: I backlog del prodotto sono documenti dinamici che cambiano continuamente. Data la loro natura a lungo termine, devono necessariamente cambiare in base alle nuove priorità, al feedback degli utenti e alle condizioni del mercato, affinché il prodotto rimanga valido.

I backlog dello sprint sono l'esatto opposto. Sebbene incoraggi vivamente a far evolvere costantemente il backlog del prodotto, modificare gli elementi di un backlog dello sprint è assolutamente sconsigliabile, poiché finiresti per infrangere tutti gli impegni e i piani del team.

Come funzionano insieme il backlog di prodotto e il backlog dello sprint

Come accennato, il backlog dello sprint è il sottoinsieme più preciso e dettagliato del backlog di prodotto. Continui comunque a considerarlo parte del backlog fino al termine dello sprint corrente. Dopodiché, le storie completate escono dal backlog, mentre quelle incomplete vi rientrano in cima all’elenco delle priorità.

Quindi, in termini di flusso delle funzionalità tra questi due backlog, potresti non solo popolare quello dello sprint con elementi provenienti dal backlog di prodotto, ma anche fare il contrario.

Indipendentemente dalla direzione in cui si spostano le storie, garantire un passaggio di consegne fluido è fondamentale. Ecco a cosa ti suggerisco di prestare attenzione:

• Qualunque elemento entri nel backlog dello sprint dovrebbe contenere le domande aperte per il team Scrum. In caso contrario, diventerai un ostacolo per l’avanzamento dello sprint. Il modo migliore per gestire questa situazione è creare insieme al team un elenco della Definizione di pronto (DoR) e seguirlo.
• Ogni elemento che entra nel backlog dello sprint dovrebbe avere delle stime. In caso contrario, gli impegni e i piani del team saranno errati. Sarebbe inoltre difficile utilizzare i grafici burndown per monitorare i progressi.
• Quando costruisci il backlog dello sprint, chiedi sempre chiaramente al team se si sente a proprio agio con il carico di lavoro. Le persone tendono a sovraccaricarsi e finiscono per completare gli sprint solo a metà.
• Quando rimuovi gli elementi incompleti dallo sprint alla sua conclusione, affronta sempre la questione durante la riunione retrospettiva. In questo modo puoi individuare l’inefficienza del processo ed eliminarla.

Nel complesso, l’intero processo si presenta così.

Oltre ai suggerimenti su come collegare questi due elementi, lasciami aiutarti a gestirli correttamente con alcune migliori pratiche basate sulla mia esperienza.

Migliori pratiche per la gestione del backlog di prodotto

Essere responsabili di un backlog di prodotto può essere piacevole o terribile, a seconda di quanto bene lo gestisci. Ecco cosa faccio sulla base di anni di esperienza:

• Pulizie costanti: trova il coraggio di rimuovere dal backlog gli elementi che hanno pochissime probabilità di arrivare allo sviluppo.
• Comunicazione con le parti interessate: organizza regolarmente riunioni di prioritizzazione di alto livello con le tue parti interessate. In questo modo, il piano che hanno in mente sarà allineato a ciò che hai nel backlog.
• Elenco separato per gli elementi dal futuro incerto: a volte tu o una parte interessata potreste avere idee che potrebbero essere sviluppate oppure no. Per evitare di ingombrare il backlog, conservatele in un elenco separato. Aggiungetele al backlog solo quando sapete che le svilupperete.

Infine, ti suggerisco di sfruttare i numerosi strumenti e modelli disponibili per un backlog di prodotto, così da velocizzare il processo di creazione. Ecco una raccolta di ClickUp che puoi utilizzare.

Se vuoi leggere altre migliori pratiche di prodotto, ti suggerisco di consultare la nostra guida dedicata.

Migliori pratiche per la gestione del backlog dello sprint

Il backlog dello sprint rappresenta l’ambito di un incremento specifico. Pertanto, i suggerimenti per gestirlo correttamente sono leggermente diversi:

• Evita una pianificazione eccessiva: gli esseri umani sono pessimi nello stimare le proprie capacità. Se il tuo team si impegna per un backlog dello sprint considerevolmente più grande del precedente, dovresti aiutarlo a rimuovere un paio di elementi.
• Gestisci gli impedimenti quotidianamente: nella mia carriera, che comprende centinaia di sprint, non ne ho mai visto uno completamente fluido. Gli impedimenti emergeranno sempre. E se non li gestisci immediatamente, le probabilità di completare lo sprint crollano. Presta quindi molta attenzione a ciò che il tuo team segnala durante le riunioni quotidiane in piedi.
• Utilizza strumenti specializzati: Internet è pieno di software creati per migliorare l’efficienza e l’efficacia dei tuoi processi Agile. Sfruttali.

Per quanto riguarda l’ultimo punto, ecco un paio di strumenti con tutte le funzionalità indispensabili che puoi prendere in considerazione.

Atlassian Jira: strumento Agile ricco di funzionalità, adatto a flussi di lavoro complessi e team numerosi.

Trello: strumento leggero per la gestione delle attività, con estensioni Agile (Kanban e Scrum), ideale per i piccoli team di nuove imprese.

Monday.com: Si colloca tra Jira e Trello. È ricco di funzionalità, ma supporta facilmente processi leggeri e team piccoli.

Per saperne di più, dai un'occhiata al nostro elenco dei migliori strumenti per la gestione dei prodotti.

Errori comuni e difficoltà nella gestione del backlog

Ho perso il conto dei fallimenti disastrosi che ho collezionato gestendo i miei backlog nel corso della mia carriera. Sebbene commettere errori sia inevitabile (è così che si impara), voglio comunque evidenziarne un paio di significativi, nella speranza che tu possa evitarli (a differenza di me).

Comportarsi da tuttologo: Questo vale soprattutto quando sei alle prime armi (ciao, effetto Dunning-Kruger). Leggi un paio di articoli sulla gestione dei backlog e pensi di saperlo fare meglio di chiunque altro. Quasi sempre porta a un gran pasticcio. Quindi, se ci sono product manager più esperti nelle vicinanze, non esitare a chiedere il loro aiuto. In alternativa, puoi anche dare un'occhiata agli esempi di backlog di prodotto gestiti correttamente.

Smettere di imparare: Il mondo Agile si evolve rapidamente. Se smetti di informarti su nuove pratiche e strumenti, finirai per affrontare problemi per i quali esistono già soluzioni aggiornate. Quindi, iscriviti a corsi o webinar sull'Agile e iscriviti alla nostra newsletter per ricevere numerose risorse e guide sulla gestione dei prodotti.

Pensare che i PM non facciano parte del team Agile: Se pensi che i PM non abbiano nulla a che fare con gli elementi inclusi nello sprint, molto probabilmente fallirai la maggior parte dei tuoi sprint. Durante l'implementazione delle storie emergono sempre domande e richieste di chiarimento relative al prodotto. Più rapidamente le risolvi, migliore sarà il risultato in termini di qualità durante la revisione dello sprint.

Tutto è una priorità e la scadenza era ieri: Conosciuta anche come “la malattia del CEO”, è un segnale che il tuo backlog non ha priorità definite. Un modo semplice per attenuare questo problema consiste nell'avere il coraggio di dire al tuo CEO: “No, non abbiamo la capacità necessaria; dimmi quale attività è più importante”. Credimi, la maggior parte dei CEO ti ascolterà e ti fornirà una priorità chiara.