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

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).

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)

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.

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).

Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help prioritize them. The key word here is "rough": estimates will change once the team fully understands and begins work on those longer term items.

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.

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.

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.