Backlog di prodotto: suggerimenti per la creazione e la definizione delle priorità

Un backlog Agile con le priorità ben definite non solo semplifica la pianificazione del rilascio e dell'iterazione, ma trasmette tutte le cose di cui il team ha intenzione di occuparsi, incluso il lavoro interno che il cliente non noterà mai. Questo contribuisce a stabilire le aspettative con gli stakeholder e gli altri team, soprattutto quando viene aggiunto altro lavoro, e rende i tempi di progettazione un cespite.

Un backlog di prodotto è un elenco con priorità del lavoro che il team di sviluppo deve svolgere, derivato dalla roadmap di prodotto e dai suoi requisiti. Gli elementi più importanti vengono mostrati nella parte superiore del backlog di prodotto, così il team sa cosa consegnare prima. Il team di sviluppo non lavora attraverso il backlog al ritmo dell'owner di prodotto e quest'ultimo non esegue il push del lavoro al team di sviluppo. Al contrario, il team di sviluppo esegue il pull del lavoro dal backlog di prodotto, poiché è possibile farlo, continuamente (Kanban) o per iterazione (Scrum).

Nel framework Scrum, il backlog di prodotto Scrum è un elenco strutturato e gestito con cura che viene utilizzato dall'owner di prodotto Scrum per guidare i task del team di sviluppo.

Prova le board Scrum di Jira

Utilizza un solo strumento di tracciamento dei ticket: non usare più sistemi per tenere traccia di bug, requisiti ed elementi di lavoro della progettazione. Se si tratta di un lavoro per il team di sviluppo, conservalo in un unico backlog.

Un backlog di prodotto ben gestito può portare numerosi vantaggi a un team di sviluppo. I vantaggi principali includono:

• Migliore definizione delle priorità: un backlog di prodotto garantisce che i task essenziali vengano risolti per primi.
• Maggiore efficienza: definendo le priorità dei task sulla base del feedback dei clienti e degli obiettivi aziendali, i team possono assicurarsi di lavorare sui task più importanti.
• Migliore comunicazione: un backlog di prodotto garantisce che tutte le persone siano allineate e lavorino per raggiungere gli stessi obiettivi.
• Riduzione degli sprechi: definendo le priorità dei task sulla base del feedback dei clienti e degli obiettivi aziendali, i team possono ridurre gli sprechi ed evitare di dedicarsi a task che non servono.
• Migliore soddisfazione del cliente: definendo le priorità dei task sulla base del feedback dei clienti, i team possono garantire di fornire le funzionalità desiderate dai clienti.

Nel complesso, un backlog di prodotto ben gestito è essenziale per lo sviluppo agile dei prodotti. Assicura che i team si dedichino ai task più importanti e che tutte le persone siano allineate e lavorino per raggiungere gli stessi obiettivi.

La roadmap e i requisiti di un team forniscono le basi per il backlog di prodotto. Le iniziative della roadmap sono suddivise in diversi epic e ogni epic avrà diversi requisiti e storie utente. Diamo un'occhiata alla roadmap per un prodotto fittizio chiamato Teams in Space.

Poiché il sito web di Teams in Space è la prima iniziativa nella roadmap, suddivideremo quell'iniziativa in epic (mostrati qui in verde, blu e verde acqua) e storie utente per ciascuno di questi epic.

L'owner di prodotto organizza tutte le storie utente in un'unica lista per il team di sviluppo. Può scegliere anche di consegnare prima un epic completo (a sinistra). In alternativa, per il programma potrebbe essere più importante testare la prenotazione di un volo scontato che richiede story provenienti da epic diversi (a destra). Vedi entrambi gli esempi di seguito.

Quali fattori possono influenzare l'assegnazione delle priorità da parte dell'owner di prodotto?

• Priorità del cliente
• Urgenza di ricevere feedback
• Difficoltà di implementazione relativa
• Relazioni simbiotiche tra gli elementi di lavoro (ad es. B è più semplice se prima facciamo A)

Un'efficace definizione delle priorità del backlog di prodotto assicura che vengano affrontati per i primi i task essenziali, bilanciando l'autonomia del team con le richieste dell'owner di prodotto.

Sebbene l'owner di prodotto abbia il compito di assegnare le priorità al backlog, questa operazione non viene compiuta in maniera decontestualizzata: gli owner di prodotto bravi raccolgono input e feedback dai clienti, dai progettisti e dal team di sviluppo per ottimizzare il carico di lavoro di tutti e la consegna dei prodotti.

La creazione di un backlog di prodotto è un passaggio cruciale nello sviluppo agile dei prodotti. Implica la creazione di una roadmap del prodotto, l'elenco degli elementi del backlog di prodotto e la comunicazione con il team.

Una roadmap di prodotto è un piano di alto livello che delinea la visione, gli scopi e gli obiettivi del prodotto. Serve come base per il backlog di prodotto e fa sì che tutte le persone siano allineate e lavorino per raggiungere gli stessi obiettivi.

Per creare una roadmap di prodotto, definisci la visione e la missione del prodotto. Quindi, identifica gli obiettivi e i traguardi chiave da raggiungere. Infine, suddividi gli obiettivi in task più piccoli e gestibili che possono essere aggiunti al backlog di prodotto.

Una volta creata la roadmap di prodotto, è il momento di iniziare a elencare gli elementi del backlog di prodotto, che possono includere funzionalità, user story, bug, modifiche alla progettazione e debito tecnico.

Quando elenchi gli articoli del backlog di prodotto, includi una descrizione chiara di ogni elemento e tutti i dettagli pertinenti, come il tempo stimato e le risorse necessarie. È inoltre essenziale definire la priorità degli elementi sulla base del feedback dei clienti, delle richieste e degli obiettivi aziendali. Questo garantisce che il team di sviluppo si dedichi a task che offrono il massimo valore.

Quando si crea un backlog di prodotto, è fondamentale una comunicazione efficace. L'owner di prodotto dovrebbe lavorare a stretto contatto con il team di sviluppo per assicurarsi che tutti comprendano il backlog di prodotto e le priorità. L'owner di prodotto dovrebbe anche comunicare con altri team, come vendite e marketing, per assicurarsi che tutte le persone siano allineate e lavorino per raggiungere gli stessi obiettivi.

Grazie a riunioni e aggiornamenti regolari, tutti possono disporre delle stesse informazioni e il backlog di prodotto è gestito in modo efficace.

Hai ancora bisogno di informazioni? Dai un'occhiata al modello gratuito di backlog di prodotto di Jira.

La definizione delle priorità del backlog è essenziale perché il team di sviluppo possa concentrarsi sui task di maggiore impatto. Ecco come approcciarla.

Diverse tecniche di definizione della priorità dei backlog, come MoSCoW e il punteggio ponderato, possono aiutare i team a gestire e ordinare i task in modo efficace. Il processo di definizione delle priorità prevede regolari attività di revisione e riallineamento degli obiettivi per adattarsi a un ambiente aziendale dinamico.

• Identifica le funzionalità o le correzioni che avranno più valore per gli utenti.
• Usa il feedback dei clienti, i sondaggi o l'analisi per individuare le priorità.

• Definisci la priorità degli elementi che genereranno informazioni utili per il team o gli stakeholder.
• Ad esempio, se i test di una nuova funzionalità vengono eseguiti prima, puoi risparmiare tempo e risorse in un secondo momento.

• Bilancia il backlog includendo risultati positivi rapidi e progetti più complessi e a lungo termine.
• Valuta il rapporto sforzo/impatto per assicurarti che le risorse vengano usate con saggezza.

• Identifica i task che devono essere completati prima di poterne svolgere altri.
• Semplifica i flussi di lavoro gestendo prima il lavoro fondamentale.

Strumenti affidabili che supportano la definizione delle priorità dei backlog possono semplificare lo sviluppo del prodotto e aumentare l'efficienza. Sebbene l'owner di prodotto sia responsabile della definizione delle priorità, il coinvolgimento del team di sviluppo, dei designer e degli stakeholder favorisce una comprensione condivisa delle priorità. Discussioni regolari assicurano l'allineamento e migliorano il processo decisionale.

Suggerimento da professionista: usa framework di definizione delle priorità, come MoSCoW (Must-have, Shoud-have, Couldhave e Won't have) o il punteggio ponderato, per prendere decisioni obiettive e basate sui dati. I team possono implementare i propri framework unici di definizione delle priorità utilizzando la funzione di definizione delle priorità flessibile di Jira Product Discovery.

Una volta creato il backlog di prodotto, è fondamentale mantenerlo per restare al passo con il programma regolarmente. Gli owner di prodotto dovrebbero controllare il backlog prima di ogni riunione di pianificazione delle iterazioni per assicurarsi che la definizione delle priorità sia corretta e che siano stati incorporati i feedback dell'ultima iterazione. La revisione regolare del backlog, spesso chiamata perfezionamento del backlog di prodotto in ambienti Agile, assicura che i task siano in linea con le informazioni degli stakeholder e prepara il team per lo sprint imminente (alcuni usano il termine affinamento del backlog).

Man mano che il backlog cresce, gli owner di prodotto devono raggrupparlo in elementi a breve e lungo termine. Gli elementi a breve termine devono essere completati interamente prima di poter essere etichettati come tali. Ciò significa che sono state redatte user story complete, è stata sistemata la collaborazione con la progettazione e lo sviluppo e sono state effettuate stime per lo sviluppo.

Gli elementi più a lungo termine possono restare vaghi, ma è comunque consigliabile ottenere una stima approssimativa dal team di sviluppo per semplificarne la definizione delle priorità. La parola chiave qui è "approssimativa", perché le stime cambieranno una volta che il team avrà compreso pienamente e inizierà a lavorare su questi elementi.

Il backlog funge da collegamento tra l'owner di prodotto e il team di sviluppo. L'owner di prodotto può ridefinire le priorità del lavoro nel backlog in qualsiasi momento in base a feedback dei clienti, stime più precise e nuovi requisiti. Tuttavia, una volta che il lavoro è in corso, le modifiche dovrebbero essere ridotte al minimo, poiché interrompono il team di sviluppo e influiscono sulla concentrazione, sul flusso e sul morale.

Suggerimento da professionista: una volta che il backlog supera la capacità a lungo termine del team, va bene risolvere i ticket di cui il team non si occuperà mai. Per ricerche future, segnala questi ticket con una risoluzione specifica, ad esempio "fuori ambito", nello strumento di tracciamento dei ticket del team.

Anti-pattern a cui prestare attenzione

• L'owner di prodotto definisce le priorità del backlog all'inizio del progetto, ma non apporta modifiche man mano che arrivano i feedback degli sviluppatori e degli stakeholder.
• Il team limita gli elementi presenti nel backlog a quelli che riguardano i clienti.
• Il backlog viene conservato come documento archiviato localmente e condiviso di rado, impedendo alle parti interessate di ricevere gli aggiornamenti.

Gli owner di prodotto esperti curano scrupolosamente il backlog di prodotto del loro programma per creare una struttura affidabile e condivisibile degli elementi di lavoro del progetto.

Gli stakeholder metteranno in discussione le priorità, e questo è un bene. Promuovere la discussione su ciò che è importante mette in sincronia le priorità di tutti. Queste discussioni favoriscono una cultura di definizione delle priorità di gruppo e garantiscono che tutti la pensino allo stesso modo sul programma.

Un backlog agile con priorità ben definite chiarisce a cosa il team intende dedicare tempo, mettendo in evidenza i task visibili e interni. Il backlog di prodotto funge anche da base per la pianificazione delle iterazioni. Deve includere tutti gli elementi di lavoro: user story, bug, modifiche alla progettazione, debito tecnico, richieste dei clienti, elementi di azione provenienti dalla retrospettiva e così via. Questo garantisce che la discussione generale includa gli elementi di lavoro di tutti i membri per ogni iterazione. I membri del team possono quindi trovare dei compromessi con l'owner di prodotto prima di iniziare un'iterazione con una conoscenza completa di tutto ciò che deve essere fatto.

Suggerimento da professionista: gli owner di prodotto definiscono la priorità degli elementi di lavoro nel backlog, mentre il team di sviluppo ne determina la velocità. Questo può essere un rapporto debole per i nuovi owner di prodotto che desiderano eseguire il "push" del lavoro al team. Questo articolo spiega i limiti e il flusso del lavoro in corso.