Backlog di prodotto: che cos'è e come crearne uno

Un backlog di prodotto sano è molto simile a un essere umano sano: curato, organizzato e che vive all'aria aperta.

Dan Radigan Di Dan Radigan
Esplora argomenti

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.

Cos'è un backlog di prodotto?

Un backlog di prodotto è un elenco con priorità del lavoro che il team di sviluppo deve svolgere, derivato dalla roadmap 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).

Suggerimento:

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.

Inizia con le due "R"

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.

Roadmap Agile | Agile Coach Atlassian

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.

Iniziative ed epic Agile | Agile Coach Atlassian

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.

Epic e story Agile | Agile Coach Atlassian

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)

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.

Come gestire efficacemente un backlog di prodotto

Una volta che il backlog di prodotto è stato creato, è importante aggiornarlo periodicamente per restare al passo con il programma. Gli owner di prodotto dovrebbero controllare il backlog prima di ogni riunione di pianificazione delle iterazioni per assicurarsi che l'assegnazione delle priorità sia corretta e che siano stati incorporati i feedback dell'ultima iterazione. Nei circoli Agile, il controllo periodico del backlog viene spesso chiamato "backlog grooming" (alcuni usano anche il termine perfezionamento 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. Questo significa che sono state redatte storie utente complete, è stata sistemata la collaborazione con la progettazione e lo sviluppo e sono state effettuate stime per lo sviluppo. Gli elementi a lungo termine possono restare più vaghi, ma è comunque consigliabile ottenere una stima approssimativa dal team di sviluppo per semplificarne la definizione della priorità. La parola chiave qui è "approssimativa": le stime cambieranno una volta che il team avrà compreso pienamente questi elementi a lungo termine e inizierà a lavorarci.

Il backlog funge da collegamento tra l'owner di prodotto e il team di sviluppo. L'owner di prodotto è libero di riassegnare le priorità del lavoro nel backlog in qualsiasi momento in base a feedback dei clienti, stime più precise e nuovi requisiti. Una volta che il lavoro è in corso, tuttavia, ti consigliamo di apportare meno modifiche possibile perché interrompono il lavoro del team di sviluppo e influenzano negativamente la concentrazione, il flusso e il morale.

Suggerimento:

Una volta che il backlog supera la capacità a lungo termine del team, i ticket di cui il team non si occuperà mai possono essere chiusi. Contrassegna questi ticket con una risoluzione specifica come "fuori ambito" nello strumento di tracciamento dei ticket del team per poterli cercare in un secondo momento.

Anti-pattern a cui prestare attenzione

  • L'owner di prodotto assegna la priorità al 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.

I backlog di prodotto mantengono i team agili

Gli owner di prodotto esperti curano scrupolosamente il backlog di prodotto del loro programma, rendendolo una descrizione affidabile e condivisibile degli elementi di lavoro per un 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 promuovono una cultura di assegnazione delle priorità di gruppo e garantiscono che tutti condividano la stessa mentalità sul programma.

Il backlog di prodotto funge anche da base per la pianificazione delle iterazioni. Esso deve includere tutti gli elementi di lavoro: storie utente, bug, modifiche alla progettazione, debito tecnico, richieste dei clienti, elementi di azione provenienti dalla retrospettiva e così via. Questo garantisce che gli elementi di lavoro di tutti i membri siano inclusi nella discussione generale 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:

Gli owner di prodotto dettano la priorità degli elementi di lavoro nel backlog, mentre il team di sviluppo stabilisce la velocity attraverso il backlog. Questo può essere un rapporto tenue per i nuovi owner di prodotto che desiderano eseguire il "push" del lavoro al team. Scopri di più nel nostro articolo sui limiti e sul flusso del lavoro in corso.

Freccia agile

Dai la priorità a ciò che conta davvero con il modello Scrum di Jira

Ottieni visibilità completa su tutto il lavoro da svolgere, così potrai concentrarti sugli elementi davvero determinanti.

Prossimo contenuto
Revisioni degli sprint