Come il backlog di prodotto si inserisce nel framework di progetto
Innanzitutto, definiamo che cos'è un backlog di prodotto. Scrum organizza i progetti in una serie di periodi di lavoro mirati chiamati sprint, ognuno dei quali dura solitamente due settimane. Prima dell'inizio dello sprint, il team e lo Scrum Master (che funge da coach) creano un backlog dello sprint, cioè un elenco delle attività che intendono portare a termine nello sprint successivo.
Il backlog dello sprint viene ricavato dal backlog di prodotto, ossia un elenco completo di tutte le caratteristiche e funzionalità da aggiungere al prodotto. Il proprietario del prodotto è responsabile della definizione delle priorità per il relativo backlog (questo soggetto rappresenta anche le esigenze del cliente e degli altri stakeholder e guida il lavoro del team di sviluppo). Il backlog di prodotto è organizzato secondo un ordine gerarchico verticale, quindi le attività più importanti sono elencate in alto e il team Scrum di solito seleziona gli elementi dal backlog in base alla priorità. Il backlog di prodotto cambierà e si evolverà nel tempo in base alle richieste degli utenti, alle necessità di business e alle tendenze tecnologiche generali.
Ricorda che puoi anche utilizzare un backlog di prodotto in un altro framework Agile chiamato Kanban. Sebbene Kanban si basi sulla limitazione dei lavori in corso (WIP) invece di utilizzare sprint a durata fissa (Scrum), le informazioni contenute in questo articolo possono essere applicate anche ai progetti Kanban.
Un backlog di prodotto ben organizzato garantisce che il lavoro sia produttivo e proficuo e che il prodotto soddisfi le esigenze dei clienti e sia in linea con gli obiettivi dell'organizzazione. Proprio come per l'elenco personale di attività da svolgere, è necessario gestire costantemente il backlog di prodotto. Questo processo è spesso chiamato raffinamento o grooming del backlog di prodotto. Le priorità cambiano, le attività vengono portate a termine e le idee vengono scartate. Senza aggiornamenti, il backlog diventerà disorganizzato e rischierà di portarti fuori strada.
Creazione del primo backlog di prodotto
Per creare un backlog di prodotto, alcuni esperti Agile consigliano di iniziare con una roadmap, ossia un piano strategico che offre una prospettiva a lungo termine per il tuo prodotto. Roman Pichler, formatore esperto in gestione Agile dei prodotti, ha affermato che molti proprietari di prodotti e manager si concentrano troppo sui dettagli delle funzionalità nelle roadmap e non abbastanza sulla visione generale. Ha sviluppato un modello di roadmap orientato agli obiettivi incentrato sull'obiettivo del prodotto e sulle funzionalità necessarie per raggiungerlo.
Sebbene la roadmap possa includere obiettivi a lungo termine per più rilasci, il backlog di prodotto dovrebbe concentrarsi sull'elencare in modo più dettagliato le attività relative al rilascio successivo. I rilasci futuri dovrebbero essere collocati più in basso ed espressi in modo meno dettagliato. A quel punto, traduci le informazioni della roadmap in attività ed elementi di lavoro.
Ogni prodotto deve avere il proprio backlog. Se il tuo è piuttosto grande o fa parte di una suite di prodotti correlati, può essere complicato determinare cosa costituisce un prodotto. L'esperto Agile Kenneth Rubin, consulente di Innolution, afferma che l'obiettivo è ridurre al minimo il numero di team e backlog di componenti, quindi preferisce utilizzare un solo backlog quando possibile. Tuttavia, per progetti molto grandi con decine o centinaia di team, questa soluzione non è pratica e in casi analoghi è possibile utilizzare i backlog gerarchici con un backlog per le funzionalità su larga scala e uno separato per ogni area di lavoro correlata.
Le user story al centro del backlog di prodotto
Gli elementi di lavoro nel backlog di prodotto sono spesso espressi in quelle che vengono chiamate user story (storie degli utenti), ossia descrizioni delle funzionalità dal punto di vista dell'utente. Le user story sono abbastanza piccole da poter essere completate all'interno di uno sprint.
Chuck Kroll, un coach Agile che ha formato i team di Fidelity Investments, raccomanda di usare una formula fissa per le user story: "In quanto (tipo di utente, ad esempio cliente), voglio (obiettivo) in modo che (motivo). Questa formula rende chiaro chi utilizzerà la funzionalità, ciò che essa comporta e il valore aziendale che offre".
User story e user epic: quanto dovrebbero essere dettagliati gli elementi di un backlog?
Una user story molto più ampia è chiamata "epic" (opera) e può richiedere diversi sprint per essere completata. Le epic devono essere suddivise in story prima di poter iniziare il lavoro.
Mike Cohn, fondatore di Mountain Goat Software, una piattaforma che offre corsi di formazione Agile e Scrum, fa questo esempio di epic: un hotel vuole adottare un sistema per determinare l'importo massimo che può addebitare per una camera a seconda di variabili come tariffe dei concorrenti, stagione, ecc. "In quanto albergatore, voglio impostare la tariffa ottimale per le camere del mio hotel." Questa epic si suddivide in user story come "In quanto albergatore, voglio impostare la tariffa ottimale per le camere in base ai prezzi dell'anno precedente" e "In quanto albergatore, voglio impostare la tariffa ottimale per le camere in base ai prezzi praticati da altri hotel simili al mio".
Nella preparazione delle user story per il backlog di prodotto, gli elementi con maggiore priorità dovrebbero contenere più dettagli affinché il team possa eseguirli accuratamente. Ciò può includere diagrammi che mostrano il flusso di lavoro di una funzionalità o una descrizione dei suoi dettagli.
"L'aspetto più importante che spesso viene trascurato è che gli elementi del backlog di prodotto non richiedono tutti lo stesso livello di dettaglio", ha affermato Cohn. "Gli elementi che fanno parte dello sprint successivo devono essere moderatamente dettagliati, mentre quelli degli altri sprint futuri dovrebbero contenere sempre meno dettagli."
Immagina la seguente user story: in quanto visitatore di un sito web, voglio essere in grado di acquistare un biglietto aereo al prezzo più basso offerto dal mio aeroporto di prima scelta o dagli aeroporti vicini. Poiché questa story si avvicina alla parte superiore del backlog di prodotto, è necessario aggiungervi dettagli come: la funzione dovrebbe controllare le tariffe applicate da tutti gli aeroporti entro 100 chilometri e darmi la possibilità di ordinare le tariffe per distanza dall'aeroporto di prima scelta e per prezzo.
Pichler sostiene che il ciclo di vita del prodotto è importante per determinare la granularità del backlog di prodotto da creare. I prodotti più recenti dovrebbero avere backlog più brevi e meno dettagliati, che ti consentono di sperimentare nuove idee e modificare frequentemente il prodotto per ottimizzarlo. D'altra parte, per i prodotti più vecchi, e quindi più stabili, è conveniente utilizzare un backlog contenente un maggior numero di dettagli, che consente di anticipare meglio l'evoluzione di tali prodotti.
Il ciclo di rilascio è un altro fattore che entra in gioco nel backlog di prodotto. Iniziare a lavorare su una nuova versione o su un rilascio di grandi dimensioni implica la presenza di più incognite, quindi le conoscenze che acquisirai si tradurranno in cambiamenti potenzialmente importanti per il tuo backlog. In conclusione, come spiega Pichler, è meglio avere un backlog di prodotto più breve e meno dettagliato all'inizio del ciclo di rilascio.
Bill Wake, un consulente Agile che ora lavora con Industrial Logic Inc, ha ideato un modello ed espediente mnemonico ampiamente utilizzato per le caratteristiche di una buona user story utilizzando l'acronimo INVEST:
I - Indipendent (Indipendente): le story non dovrebbero sovrapporsi e idealmente possono essere implementate in qualsiasi ordine.
N - Negotiable (Negoziabile): la story racchiude l'essenza ma non i dettagli, che sono concordati dai partecipanti.
V - Valuable (Preziosa): la story offre un valore chiaro al cliente.
E - Estimable (Stimabile): è possibile valutare lo sforzo richiesto. Potrebbe trattarsi di una stima temporale o, in quelli che vengono chiamati story point (punti della story), di un'unità di misura arbitraria che valuta la complessità relativa (come XS, S, M, L, XL o 1, 2, 4, 8, 16).
S - Small (Piccola): "Le story migliori tendono a essere piccole", afferma Wake. Ciò significa che la story dovrebbe essere completata da una persona designata entro non più di alcune settimane lavorative da 40 ore o divisa tra i membri del team.
T - Testable (Testabile): secondo Ulf Eriksson, fondatore e product owner della piattaforma di test IT ReQtest, la user story dovrebbe essere misurabile o fruibile in qualche modo.
Altri elementi che rientrano nel backlog di prodotto
Cohn ha sottolineato che non tutti gli elementi del backlog devono essere una user story. "Mi capita di incontrare team che pensano che ogni elemento del backlog di prodotto debba essere una user story. Le user story sono molti utili, ma solo se vengono effettivamente coinvolti degli utenti. Alcuni elementi appartenenti a un backlog di prodotto non sono rivolti direttamente agli utenti e non devono essere scritti come user story."
Tra questi elementi ricordiamo il lavoro sul back-end e altre attività che non riguardano gli utenti. Cohn consiglia di descrivere queste attività utilizzando la sintassi Feature-Driven Development (FDD): verbo + risultato + oggetto, come "Convalidare la password di un utente".
I quattro tipi di elementi che si trovano comunemente nei backlog Scrum sono funzionalità, bug, lavoro tecnico e acquisizione di conoscenze. Le funzionalità di solito si prestano a essere espresse come user story, mentre gli altri elementi no.
Se sei alle prime armi, non preoccuparti: non devi per forza iniziare il tuo progetto con un backlog di prodotto perfetto. Comincia da un brainstorming delle attività necessarie per ottenere informazioni sufficienti per il tuo primo sprint. Dopodiché, puoi espandere il backlog man mano che acquisisci più dati sul prodotto, sulle esigenze degli utenti e sul loro feedback.
"Il mio consiglio principale per quanto riguarda i backlog di prodotto è quello di prediligere la semplicità. Il backlog non è altro che una struttura ordinata di ripartizione del prodotto", ha affermato Laurens Bonnema, consulente Agile presso Xebia nei Paesi Bassi.
C.J. Boat, team leader Agile per il marketplace di assicurazioni Ensurem, è d'accordo. "Bisogna fare in modo che le aspettative siano ragionevoli. Se lasci che il backlog diventi troppo articolato o non organizzi correttamente il lavoro, il backlog e gli sprint possono diventare così intricati da risultare inutili", ha affermato.
Definizione delle priorità e ordinamento del backlog di prodotto
Una volta aggiunte le attività, è il momento di ordinare il backlog di prodotto. Metti in alto i lavori più importanti e in basso quelli meno importanti in base alla tua valutazione delle priorità, riflettendo su come classificare gli elementi con la stessa priorità nel corso del lavoro.
"Quando aggiungi attività al tuo backlog, assegna loro una valutazione di priorità iniziale", ha affermato Kevin Lonergan, Principal Project Management Consultant presso la società britannica PMIS Consulting. "Una semplice gerarchia delle priorità a tre livelli andrà bene: 1 - fondamentale per raggiungere gli obiettivi aziendali, 2 - utile ma non critico, 3 - la realizzazione di questi elementi è un bonus."
Alcuni professionisti affermano che un metodo migliore consiste nell'ordinare l'elenco in base ad altri criteri come il rischio, il ROI, il rapporto costi/benefici, un modello a compartimenti come MoSCoW (deve, dovrebbe, potrebbe, non sarà), l'impatto che una story ha su un'altra, il tempo stimato per l'implementazione o le dipendenze.
Bonnema di Xebia predilige il metodo Weighted Shortest Job First (WSJF), descritto da Donald Reinertsen in "The Principles of Product Development Flow" e sviluppato ulteriormente da Dean Leffingwell, creatore dello Scaled Agile Framework. Si tratta di una formula per dare priorità al backlog di prodotto in base alla durata delle attività e alla stima dei costi derivanti da eventuali ritardi. "Non ho trovato un metodo migliore del WSJF per assegnare le giuste priorità ai backlog a tutti i livelli", ha affermato Bonnema. Le attività rimangono nel backlog di prodotto fino al loro completamento o fino a quando il proprietario del prodotto non decide che non sono più necessarie.
Per determinare quando una user story è completata e può essere rimossa dal backlog, i team dovrebbero sviluppare una definizione di "fatto" standardizzata, ovvero i criteri di accettazione di una funzionalità che garantisce che tutti i membri del team sappiano quali sono le aspettative riguardo al lavoro da consegnare. Kelly Waters, autore di All About Agile, ritiene che "fatto" dovrebbe significare spedibile. Jeff Sutherland, CEO di Scrum Inc., utilizza la famosa formula Agile "fatto fatto", 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 di "fatto" del tuo team è soddisfatta, un elemento può essere spostato dal backlog di prodotto alla colonna degli elementi completati.
Come creare un backlog di prodotto passo passo
Ora che sai cos'è un backlog di prodotto e quali sono gli elementi che include e non include, ecco una checklist che puoi utilizzare per creare il tuo primo backlog:
- Il proprietario del prodotto è responsabile del relativo backlog. Se il proprietario sei tu, dovrai creare il backlog di prodotto, ma puoi farlo anche insieme ad altre persone. Ad esempio, possono partecipare i membri del team Scrum e altri stakeholder.
- Ricorda che il backlog di prodotto è l'elenco completo di tutte le user story e di altri elementi di lavoro relativi al prodotto.
- Scrivi tutte le attività che ti vengono in mente. Inserisci quanti più dettagli possibili e chiedi input a tutte le parti coinvolte nella tua organizzazione e raccogli il feedback dei clienti.
- Crea story dal punto di vista dell'utente e includi un'azione e un motivo (in quanto _, voglio _, in modo che _) pensando a tutte le tipologie di utente. Scrivile su cartellini indice o usa uno strumento online. Applica tag per rendere chiaro il rilascio pianificato.
- Includi correzioni di bug, acquisizione di conoscenze e lavoro tecnico.
- In qualità di proprietario del prodotto, solo tu valuti l'importanza che ogni elemento ha per l'organizzazione su una scala d'importanza che va da "molto alta" a "molto bassa" oppure utilizzando un altro metodo. È possibile intervistare gli utenti per avere una base solida per prendere queste decisioni.
- Per ogni elemento di lavoro, fornisci anche una stima dell'impegno richiesto.
- Classifica il backlog di prodotto.
- Il lavoro che il team si impegna ad affrontare in uno sprint corrisponde al backlog dello sprint, che è separato dal backlog di prodotto e non cambia durante lo sprint. Gli elementi vengono considerati completi e rimossi sia dallo sprint che dal backlog di prodotto quando sono "fatti fatti".
- All'arrivo di un nuovo lavoro, aggiungilo al backlog di prodotto nella posizione giusta. Ogni volta che raccogli nuove informazioni, ad esempio un feedback, puoi eliminare o riordinare gli elementi.
Al termine di questo processo, otterrai un elenco simile al seguente:
A questo punto, le congratulazioni sono d'obbligo se hai redatto con successo il tuo primo backlog di prodotto e hai fatto lavorare il tuo team Scrum su una serie di user story preziose in uno sprint. Ma non è finita qui.
Mantenere aggiornato il backlog di prodotto
Una volta creato, il backlog di prodotto deve essere continuamente mantenuto e aggiornato. Grazie a questo processo, noto anche come grooming o raffinamento del backlog di prodotto, il backlog rimane sempre aggiornato in base alle informazioni provenienti dal mercato, dagli utenti, dal team di prodotto e dalla dirigenza dell'organizzazione. Mantenendo il controllo del backlog, potrai assicurarti che il team di sviluppo si dedichi sempre alle attività più rilevanti, di avere tutto pronto per affrontare lo sprint successivo e di utilizzare bene le tue risorse per fornire il miglior prodotto possibile al cliente.
Un modo semplice per ricordare l'obiettivo del processo di raffinamento del backlog di prodotto è l'acronimo DEEP. Il tuo obiettivo è assicurarti che il backlog di prodotto rispetti sempre questo acronimo:
D - Detailed (Dettagliato): il backlog deve essere realizzato in modo che gli elementi in cima all'elenco contengano più dettagli di quelli in fondo.
E - Estimated (Previsto): ogni elemento del backlog di prodotto, o almeno quelli coinvolti nel rilascio successivo, deve essere previsto in base agli story point o al tempo. Man mano che il tuo team ottiene più lavoro, la sua velocità, ovvero la frequenza con cui termina gli elementi del backlog di prodotto, diventerà più chiara e renderà più facile la formulazione di queste previsioni.
E - Emergent (In divenire): il backlog di prodotto viene adattato a nuovi elementi o informazioni che emergono nel corso dei lavori.
P - Prioritized (Priorizzato): tutti gli elementi del backlog di prodotto sono elencati in ordine di importanza decrescente.
I migliori suggerimenti dei professionisti sulla gestione del backlog di prodotto
Pur impegnandosi al massimo per mantenere sotto controllo il backlog di prodotto, possono sempre insorgere problemi tecnici. Gli esperti Agile che hanno lavorato con molti team e su un'ampia varietà di progetti hanno alcuni suggerimenti su come risolvere e prevenire eventuali problemi.
Il coach Agile Kroll ha affermato che i problemi più frequenti derivano dalla mancanza di partecipazione da parte degli sponsor di progetto, che devono essere coinvolti quotidianamente, e dalla tendenza a spingere il team a rispettare tempistiche che esulano dal suo rendimento effettivo. La soluzione è che i manager passino da una mentalità tradizionale basata sul confronto tra le attività di progetto pianificate e quelle portate a termine a un approccio Agile.
Jonathan Roger, project manager e Scrum Master per AndPlus, suggerisce di mantenere un "freezer" nella parte inferiore del backlog di prodotto per congelare le idee non prioritarie e non sottoposte a grooming. "I proprietari dei prodotti possono tenere traccia delle funzionalità desiderate a lungo termine senza la pressione di mantenerle in un ordine di priorità e i team possono aggiungere idee da sottoporre all'attenzione dei proprietari. Questo approccio è anche un buon punto di partenza per le richieste di funzionalità da parte di clienti o stakeholder."
Lonergan di PMIS Consulting consiglia di effettuare un'attenta selezione del proprietario di prodotto come chiave per il successo. "Il ruolo di proprietario di prodotto deve essere svolto da una sola persona, non da un comitato", ha sottolineato. "Dal momento che questa persona detiene il backlog di prodotto, dovrai assicurarti che ne promuova lo sviluppo."
"L'errore principale è senza dubbio quello di nominare la persona sbagliata come proprietario di prodotto a causa della mancanza di autorità, conoscenza nel campo, tempo, ecc.", ha aggiunto Lonergan.
Mantenere e gestire facilmente i backlog di prodotto con Smartsheet
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.