I migliori consigli di esperti Scrum e Agile sulla gestione del product backlog

Innanzitutto definiamo chiaramente il backlog di prodotto. Scrum organizza i progetti in una serie di periodi di lavoro dedicati, chiamati sprint, e ogni sprint dura solitamente due settimane. Prima che inizi uno sprint, il team e lo Scrum master (che funge da coach) creano il loro backlog sprint, ovvero un elenco di ciò che intendono portare a termine nello sprint successivo. 

Il backlog di sprint è tratto dal backlog di prodotto più ampio, che è un elenco completo di tutte le caratteristiche e le funzionalità che devono essere aggiunte al prodotto. Il proprietario del prodotto è responsabile delle priorità del backlog di prodotto. (Il proprietario del prodotto rappresenta anche le esigenze del cliente e degli altri stakeholder e guida il lavoro del team di sviluppo). Il backlog del prodotto viene classificato in verticale in modo che le attività più importanti siano elencate in alto e il team Scrum seleziona solitamente gli elementi dal backlog in base alla priorità. Il backlog del prodotto cambierà e si evolverà nel tempo in base alle richieste degli utenti, alle esigenze aziendali e ai trend tecnologici più ampi.

Come nota a margine, è possibile utilizzare un product backlog anche in un altro framework Agile chiamato Kanban. Sebbene Kanban si basi sulla limitazione del lavoro in corso (WIP) anziché sull'uso di sprint di lunghezza fissa (Scrum), le informazioni contenute in questo articolo possono essere applicate anche ai progetti Kanban.

Un backlog si prodotto ben costruito assicura che il tuo lavoro sia produttivo e prezioso, che il prodotto soddisfi le esigenze dei clienti e si allinei agli obiettivi della tua azienda. Come per la tua lista personale di "cose da fare", devi costantemente gestire il backlog del prodotto. Questo processo è spesso chiamato affinamento o "gestione" del backlog di prodotto. Le priorità cambiano, i compiti vengono portati a termine e le idee vengono scartate. Senza aggiornare il tuo backlog, tutto ciò diventerà disorganizzato e non ti aiuterà a rimanere sempre aggiornato.

Per iniziare a creare un backlog di prodotto, alcuni esperti di Agile consigliano di iniziare con una roadmap del prodotto. Questo è un piano strategico che offre prospettive a lungo termine per il tuo prodotto.  Roman Pichler, formatore esperto nella gestione dei prodotti Agile, afferma che molti product owner e manager si concentrano troppo sui dettagli delle funzionalità nelle loro roadmap e non abbastanza sul quadro generale. Ha sviluppato un modello di roadmap orientato agli obiettivi, che sottolinea l'obiettivo del prodotto e le funzionalità necessarie per raggiungerlo.
 
Mentre la tua roadmap potrebbe includere obiettivi a lungo termine per diversi rilasci, il backlog di prodotto dovrebbe concentrarsi sul lavoro per il prossimo rilascio in dettaglio. I rilasci futuri dovrebbero essere collocati più in basso ed espressi in modo meno dettagliato. Quindi prendi le informazioni dalla roadmap e traducile in attività e voci di lavoro. 

Ciascun prodotto dovrebbe avere il proprio backlog. Se il tuo prodotto è abbastanza ampio o parte di una serie di prodotti interconnessi, può essere difficoltoso determinare cosa costituisce un prodotto. L'esperto di Agile Kenneth Rubin, consulente di Innolution, afferma che il traguardo è di ridurre al minimo il numero di team e di backlog di componenti, quindi preferisce utilizzare un unico backlog ogni volta che è possibile. Tuttavia, per progetti molto grandi con decine o centinaia di team, questo non è pratico, e in questi casi i backlog gerarchici possono essere utilizzati con un backlog su larga scala e un backlog separato per ogni area di lavoro correlata.

Le voci di lavoro del backlog di prodotto sono spesso espresse in quelle che vengono chiamate user story, una descrizione di come dovrebbe essere la funzionalità dal punto di vista dell'utente. Una user story è abbastanza piccola che può essere completata all'interno di uno sprint. 

Chuck Kroll, un coach di Agile che ha supervisionato i team presso Fidelity Investment, consiglia una formula tradizionale per le user story:  “Come utente (tipo di utente, ad esempio il cliente), vorrei (obiettivo) affinché (motivo)," ha detto Kroll. “In questo modo è chiaro chi utilizzerà la funzionalità, ciò che comporta e il valore aziendale che offre.”

User story vs. User epic: Quanto devono essere dettagliate le voci del backlog?

Una user story molto più ampia è chiamata "epic" e può richiedere diversi sprint per essere realizzata. L’epic deve essere suddiviso in user story prima che il lavoro possa iniziare. 

Mike Cohn, fondatore di Mountain Goat Software che offre formazione Agile e Scrum, riferisce questo esempio di user epic: una società alberghiera vuole un sistema per determinare il prezzo massimo che può applicare a una camera d'albergo in base a variabili quali le tariffe dei concorrenti, la stagione, ecc. “Come operatore alberghiero, desidero impostare la tariffa ottimale per le camere nel mio hotel.” Questo si traduce in user story, in quanto "come operatore alberghiero, desidero impostare la tariffa ottimale per le camere in base ai prezzi dell'anno precedente" e "come operatore alberghiero, desidero impostare la tariffa ottimale per le camere in base ai prezzi praticati da hotel simili al mio".

Quando prepari le user story per il backlog del prodotto, gli elementi di priorità superiore dovrebbero avere più dettagli per aiutare il team a eseguirli accuratamente. Ciò può includere diagrammi che mostrano il flusso di lavoro di una funzionalità o una sua descrizione particolareggiata. 
"Il consiglio più importante che vedo trascurato è che le voci del product backlog non devono avere tutte lo stesso livello di dettaglio", dichiara Cohn. “Gli elementi che vengono inseriti nello sprint successivo devono essere moderatamente dettagliati. Gli elementi da qui in avanti dovrebbero essere progressivamente meno dettagliati.”

Ipotizziamo la seguente user story: come visitatore di un sito web, voglio essere in grado di acquistare un biglietto aereo al prezzo più economico offerto per il mio aeroporto di prima scelta o per gli aeroporti vicini. Poiché si trova in cima al backlog del prodotto, dovreste aggiungere dati alla user story, come: la funzione dovrebbe controllare le tariffe per tutti gli aeroporti nel raggio di 100 miglia; dovrebbe darmi la possibilità di ordinare le tariffe per distanza dall'aeroporto di prima scelta e per prezzo. 

Pichler afferma che il ciclo di vita del prodotto è importante per decidere quanto debbano essere dettagliati i dati del backlog di prodotto. I prodotti giovani dovrebbero avere backlog più brevi e meno dettagliati, che consentano di sperimentare nuove idee e di modificare frequentemente il prodotto per ottimizzarlo. D'altra parte, i prodotti meno recenti e più stabili beneficiano di un backlog più dettagliato che è più in grado di anticipare come il prodotto si evolverà.

Il ciclo di rilascio è un altro fattore rilevante del backlog di prodotto. Quando si inizia a lavorare su una nuova versione o su una release importante, ci sono più incognite e ciò che si impara comporterà potenzialmente grandi modifiche al backlog. Spiega Pichler che quindi un backlog di prodotto più breve e meno dettagliato ha senso all'inizio del ciclo di rilascio. 

Bill Wake, consulente Agile che ora collabora con Industrial Logic Inc, ha fornito un modello ampiamente utilizzato e memorizzabile per le caratteristiche di una buona user story, utilizzando l'acronimo INVEST:

I - Indipendente - Le user story non devono sovrapporsi e possono essere implementate in qualsiasi ordine.
N - Negoziabile - Il racconto cattura l'essenza ma non i dettagli, che vengono accettati dai partecipanti.
V - Di valore (Valuable) - La user story deve offrire un chiaro valore al cliente. 
E - Stimabile (Estimable) - Essere in grado di valutare lo sforzo necessario. Può trattarsi di una stima del tempo o punti user story, un'unità di misura arbitraria che valuta la complessità relativa (come XS, S, M, L, XL o 1, 2, 4, 8, 16). . Questo potrebbe essere una stima temporale o dei cosiddetti punti della user story, un'unità di misura arbitraria che valuta la complessità relativa (come XS, S, M, L, XL o 1, 2, 4, 8, 16). 
S - Piccolo (Small) - "Le buone user story tendono ad essere piccole", afferma Wake. Significa che una user story dovrebbe essere completata (in genere) in alcune settimane di lavoro da 40 ore da una persona dedicata o divisa tra i membri del team. 
T - Verificabile (Testable) - La user story dovrebbe essere misurabile o attuabile in qualche modo, secondo Ulf Eriksson, fondatore e product owner della piattaforma di testing IT ReQtest.

Cohn ha sottolineato che non tutti gli elementi del backlog devono essere una user story. "Incontro dei team che pensano che ogni voce del backlog del prodotto debba essere una user story. Le user story sono ottime, quando ci sono degli utenti. Ma alcune cose che appartengono al backlog di un prodotto non sono necessariamente direttamente per gli utenti. Questi elementi non devono essere scritti come user story.” 

Ciò include il lavoro sul backend o altri compiti che sono lontani dagli utenti. Cohn raccomanda di descrivere questi compiti utilizzando la sintassi dello sviluppo, basata su funzioni (FDD) (verbo + risultato + oggetto, ad es., “convalidare la password di un utente”).
I quattro tipi di elementi comunemente presenti sui backlog Scrum sono funzionalità, bug, lavoro tecnico e acquisizione di conoscenze. Le funzionalità si prestano solitamente ad essere riportate come user story, al contrario degli altri elementi.. 

Se sei solo agli inizi, non ti preoccupare: non è necessario iniziare il progetto con un backlog di prodotto perfetto. Inizia facendo brainstorming delle attività necessarie e questo fornirà abbastanza informazioni per il tuo primo sprint. Successivamente, puoi espandere il backlog di prodotto, per saperne di più sul prodotto, sulle esigenze dell'utente e sul feedback.

“I miei consigli principali sul backlog di prodotto sono di mantenerli semplici. È solo una struttura ordinata di ripartizione dei prodotti", ha dichiarato Laurens Bonnema, consulente Agile presso Xebia in Olanda.

C.J. Boat, responsabile del team Agile per il marketplace assicurativo Ensurem, concorda. “Crea aspettative ragionevoli! Se si lascia che il backlog diventi troppo voluminoso o non si organizza correttamente il lavoro, il backlog e gli sprint possono diventare così affollati da crollare", afferma. 

Dopo aver aggiunto le attività, è tempo di fare ordine nel backlog di prodotto. Posiziona il lavoro più importante al di sopra di quello meno importante. Puoi realizzarlo in base alla tua classificazione delle priorità, valutando man mano come classificare gli elementi con la stessa priorità.

“Durante l'aggiunta di attività al tuo backlog, assegna loro una valutazione di priorità iniziale", afferma Kevin Lonergan, Principal Project Management Consultant presso la società britannica PMIS Consulting. “Una semplice priorità a tre livelli è sufficiente: 1 - fondamentale per raggiungere gli obiettivi aziendali, 2 - utile ma non critico, 3 - sarebbe un bonus se questi elementi venissero realizzati.”

Secondo alcuni esperti, un metodo migliore consisterebbe nell'ordinare l'elenco in base ad altri criteri, come il rischio, il ROI, il rapporto costi-benefici, un modello a fasce come il MoSCoW (must have, should have, could have, won't have), l'impatto di una user story su un'altra, il tempo stimato per l'implementazione o le dipendenze.

Bonnema di Xebia preferisce il metodo Weighted shortest job first (WSJF), scritto da Donald Reinertsen in “The Principles of Product Development Flow” e sviluppato ulteriormente da Dean Leffingwell, creatore dello Scaled Agile Framework. È una formula per stabilire la priorità del backlog di prodotto, in base alla durata delle attività e a una ponderazione del costo del ritardo. “Non ho trovato un modo migliore di WSJF per assegnare correttamente le priorità ai backlog a ogni livello", dichiara Bonnema. Le attività rimangono nel backlog di prodotto fino a quando non vengono completate o fino a quando il product owner decide che non sono più necessarie. 

Per determinare quando una user story è completata e può essere rimossa dal backlog, i team devono sviluppare una "definizione di fatto" standardizzata. Si tratta dei criteri di accettazione di una funzionalità che assicurano che tutti i membri del team sappiano cosa ci si aspetta dal lavoro che consegnano. Kelly Waters, autrice di All About Agile afferma che "fatto” dovrebbe significare spedibile. Jeff Sutherland, CEO di Scrum Inc., utilizza la nota espressione di Agile "done done", che significa che alla fine dello sprint, la codifica è stata completata e il test del software è terminato a livello di funzionalità senza bug. Quando la definizione del team di “fatto” viene soddisfatta, un elemento può essere spostato dal backlog di prodotto nella colonna dei progetti completati.

Ora che hai approfondito che cos'è un backlog di prodotto e cosa deve o non deve contenere, ecco la tua checklist per creare il tuo primo backlog di prodotto:

1. Il product owner è responsabile del backlog di prodotto. Se sei tu, sei responsabile della creazione del backlog di prodotto, ma non sei l'unica persona coinvolta. I membri del team Scrum e gli altri stakeholder possono partecipare.
2. Ricorda che il backlog di prodotto è l'elenco completo di tutte le user story e altri elementi di lavoro per il prodotto.
3. Pensa a ogni attività possibile e scrivila. Sii il più specifico possibile e chiedi il contributo di tutte le parti interessate della tua azienda e il feedback dei clienti.
4. Realizza user story dal punto di vista dell'utente e includi un'azione e un motivo. (come _, vorrei _, affinché_.) Pensa a tutti i diversi utenti. Scrivi le informazioni su schede o utilizza uno strumento on-line. Applica dei tag per rendere chiara la release prevista.
5. Includi le correzioni di bug, l'acquisizione di conoscenze e il lavoro tecnico.
6. In qualità di product owner, dovrai valutare l'importanza di ciascun elemento per l'organizzazione, da molto alta a molto bassa, o con un altro metodo. È possibile fare un sondaggio tra gli utenti per avere una solida base per queste decisioni. 
7. Per ogni voce di lavoro, fornisci anche una stima dell'impegno richiesto.
8. Classifica il backlog di prodotto. 
9. Il lavoro che il team si impegna ad affrontare in uno sprint è il backlog dello sprint, distinto dal backlog di prodotto. Il backlog dello sprint non cambia durante lo sprint. Gli elementi sono considerati completati e rimossi sia dal backlog di sprint che di prodotto quando vengono eseguiti.”
10. Quando viene fornito un nuovo lavoro, è necessario aggiungerlo al backlog di prodotto nella posizione corretta. Quando raccogli nuove informazioni come il feedback, puoi eliminare o riordinare le voci. 

Al termine, si dovrebbe ottenere qualcosa di simile a questo:

A questo punto, le congratulazioni sono d'obbligo se sei riuscito a redigere il tuo primo product backlog e a far lavorare il tuo team Scrum su un gruppo di user story di valore in uno sprint. Ma non è ancora il momento di rilassarsi...

Una volta creato, il backlog di prodotto deve essere continuamente aggiornato. Questo processo, noto anche come "product backlog grooming" o "refinement", consente di mantenere aggiornato il backlog sulla base delle informazioni provenienti dal mercato, dagli utenti, dal team di prodotto e dal management dell'azienda. Mantenendo l'attenzione sul backlog, ti assicuri che il team di sviluppo si dedichi sempre alle cose giuste, che siate pronti per il prossimo sprint, che utilizziate bene le vostre risorse e che forniate il miglior prodotto possibile ai vostri clienti. 

Un modo semplice per ricordare l'obiettivo del processo di aggiornamento del backlog di prodotto è l'acronimo DEEP. Il tuo obiettivo è assicurarti che il backlog del prodotto sia sempre DEEP: 

D - Dettagliato in modo appropriato, in modo che le voci in cima all'elenco siano più dettagliate di quelle in fondo. 
E- Stimato (Estimated) - Ogni elemento di backlog di prodotto, o almeno quelli coinvolti nel rilascio successivo, dovrebbe essere stimato in base a punti di user story o al tempo. Man mano che il tuo team si impegna di più, la sua velocità (la velocità a cui finisce gli elementi del backlog di prodotto), renderà le cose più chiare e faciliterà la stima.
E- Emergente - Significa che il backlog di prodotto si adatta a nuovi elementi o informazioni che emergono.
P- Priorità - Tutte le voci del backlog di prodotto sono ordinate a partire dalle più importanti nella parte superiore. 

Pur impegnandoti per mantenere il backlog di prodotto senza intoppi, possono verificarsi degli inconvenienti. Gli esperti di Agile che hanno lavorato con molti team e su una varietà di progetti hanno dei consigli per risolvere ed evitare i problemi.

Il coach Kroll di Agile afferma che i problemi più comuni da lui notati, derivano da una mancanza di partecipazione da parte degli sponsor del progetto, che devono essere coinvolti quotidianamente, e dalla tendenza di questi ultimi a fare pressione sul team per raggiungere obiettivi temporali che non sono guidati dalla produzione effettiva del team. La soluzione è che i manager passino da una mentalità tradizionale di progetto "pianificato vs. effettivo" a un approccio Agile. 

Jonathan Roger, project manager e Scrum master per AndPlus, consiglia di "congelare" in fondo al backlog di prodotto tutte le idee non prioritarie e non aggiornate. “I product owner possono tenere traccia delle funzionalità a lungo termine senza la pressione di mantenerle in un ordine prioritario e i team possono aggiungere le loro potenziali idee per la revisione da parte del product owner. Serve anche come punto di partenza efficace per le richieste di funzionalità da parte dei clienti o degli stakeholder.” 

Lonergan di PMIS Consulting raccomanda un'attenta selezione del product owner come chiave per il successo. “Una persona deve svolgere il ruolo di product owner, non un comitato", ha sottolineato. "È il proprietario del backlog di prodotto. Assicuratevi che il product owner guidi lo sviluppo del backlog".

“L’ (errore) n.1 è senza dubbio designare la persona sbagliata come product owner a causa di una mancanza di autorità, conoscenza del dominio, mancanza di tempo, ecc.", aggiunge Lonergan. 

Dalla semplice gestione delle attività e pianificazione dei progetti, alla complessa gestione delle risorse e del portfolio, Smartsheet ti aiuta a migliorare la collaborazione e ad aumentare la velocità del lavoro, consentendoti di ottenere di più. La piattaforma Smartsheet semplifica la pianificazione, l'acquisizione, la gestione e la creazione di report sul lavoro da qualsiasi luogo, aiutando il tuo team a essere più efficace e ottenere di più. Crea report sulle metriche chiave e ottieni visibilità in tempo reale sul lavoro mentre accade con report di riepilogo, pannelli di controllo e flussi di lavoro automatizzati creati per mantenere il tuo team connesso e informato. Quando i team hanno chiarezza sul lavoro da svolgere, possono ottenere maggiori risultati in meno tempo. Prova Smartsheet gratuitamente, oggi.