La Scrum Guide definisce il product backlog come “un elenco ordinato di ciò che è necessario per migliorare il prodotto”.
Xavier Koma dà una definizione ancora più precisa dicendo che si tratta di una lista ordinata di tutte le funzionalità/item, poco importa la forma o il formato dell’item, che può essere user story, specifiche, brief, un modello con powerpoint o gherkin. L’unica condizione è che il team concordi il formato, in modo da mantenere la stessa comunicazione e comprensione.
Differenze tra book of specification e product backlog
Chi è responsabile del product backlog?
Il Product Owner è responsabile del backlog e generalmente lo definisce insieme al team che lavorerà alle users story in modo che siano pronti per essere supportati dagli sviluppatori. Può essere che il team di sviluppo rediga le user story da un punto di vista tecnico, ma è sempre il Product Owner che deve prioritizzare l’insieme degli item.
Product Backlog: cos’è e quali sono le sue caratteristiche?
Il product backlog ha alcune caratteristiche principali. Claude Aubry le ha sintetizzate utilizzando l’acronimo “prouvé” (dimostrato, provato):
Pubblico (publique): tutta l’organizzazione deve avere accesso al product backlog, si tratta di una questione di visibilità e allineamento.
Ridotto(réduit): il product backlog deve essere molto corto, generalmente tra i 40 e i 60 item.
Ordinato (ordonné): gli item sono ordinati secondo ordine decrescente, ovvero l’item che rappresenta maggior valore si trova in cima. Il Product Owner può utilizzare diverse tecniche Agile per ordinare il backlog.
Unico(unique): un solo product backlog per prodotto!
Vivo(vivant): il Product Owner può benissimo riordinare il product backlog a suo piacimento in funzione delle esigenze emergenti del prodotto.
Emergente(émergent): il backlog non è mai completo, cambia costantemente ed è sempre possibile aggiungere nuovi item o nuove funzionalità.
Come costruire un backlog? Quali sono gli step?
Source : Eden tech labs
Il product backlog è un importante artefatto della metodologia Scrum ed è il principale strumento di lavoro del Product Owner. Ecco i 5 passi più importanti per gestire un backlog in modo efficace:
Identificare i bisogni
Scrivere le user story
Prioritizzare il product backlog
Verificare il livello di qualità delle user story
Aggiungere criteri di accettazione
Identificare i bisogni
Prima di tutto, è necessario stabilire la visione del progetto, ovvero definire chiaramente l’obiettivo che il progetto deve raggiungere e di identificare le diverse parti coinvolte. È importante che questa visione sia accettata e compresa da tutti, ed è necessario che abbia il consenso delle parti coinvolte, poiché il team dovrà unirsi al Product Owner per realizzare questo progetto seguendo l’obiettivo.
Scrivere le user story
Arriva poi il momento di redigere le user story tenendo a mente alcune domande fondamentali: Quali saranno le funzionalità da creare? In quale ordine dovranno essere consegnate? A chi sono destinate?
Il product backlog può essere organizzato secondo diversi criteri:
Tematiche: raggruppamento logico di un certo numero di argomenti definiti dal Product Owner. Non c’è una regola assoluta, l’importante è che l’organizzazione sia ottimale. Questi temi sono poi suddivisi in base alle feature.
Feature: raggruppamento di user story. Ogni feature rappresenta un grosso blocco funzionale, ovvero una importante funzionalità del prodotto. Queste funzionalità saranno suddivise in item, anche chiamati user story.
User story: le user story o item o attività o ancora elementi di backlog, sono diversi modi di definire miglioramenti, evoluzioni, funzionalità, funzioni o bug.
Sotto attività: il team di sviluppo, per esempio in Scrum, suddivide l’insieme degli item in sottoparti tecniche durante lo sprint planning, o anche in sotto-compiti anomali.
Ma quindi EPIC che cosa significa?
La definizione di “EPIC” non è univoca: in un ambiente SAFe, ad esempio, è il primo livello che precede anche il tema, rimanendo a livello macro.
Da una parte l’EPIC può essere allo stesso livello di una feature o di un tema, ma alla base la definizione iniziale di EPIC è quella di una grande storia, un bisogno, con poca visibilità. Questo famoso EPIC si suddivide in più user story. Si parla allora di maturazione dell’EPIC in user story.
Ci sono più significati possibili, il più importante è che il team determina la propria definizione a cui tutti devono allinearsi
Prioritizzare il product backlog
Quando il Product Owner deve dare delle priorità al product backlog, si scontra spesso con un problema comune: un processo di prioritizzazione vago e incoerente. In qualità di Product Owner, ricevete dei commenti quotidiani, delle nuove idee e delle domande di funzionalità da diverse parti interessate e ovviamente non si può accontentare tutti.
Le parti interessate possono essere confuse riguardo al fatto che voi abbiate scelto di dare priorità ad alcuni item piuttosto che altri e potrebbero avere la sensazione di non avere abbastanza influenza sul vostro processo di prioritizzazione.
Uno step importante per risolvere questi problemi, consiste nello standardizzare il processo di gerarchizzazione. Per questo motivo esistono diverse tecniche:
Queste tecniche creano un approccio riproducibile, più trasparente e meno aleatorio secondo la prioritizzazione.
Verificare il livello di qualità delle user story
Il Product Backlog Refinement, anche noto con il nome di Backlog grooming, è una pratica Scrum che ha l’obiettivo, come indica il suo nome, di affinare il contenuto del product backlog. È un momento ideale per verificare la qualità di una user story insieme a tutto il team e di rimetterla in questione. Grazie agli input di ognuno, il/la Product Owner potrà migliorare le user story selezionate per lo sprint.
Prima di lanciare un’interazione (ciclo che varia da 1 a 4 settimane), il/la product Owner e il suo team devono assicurarsi che le user story siano realizzabile da una sola persona e all’interno di un’iterazione.
Aggiungere criteri di accettazione
Al fine di ottimizzare le user story, il team deve definire insieme, durante il Backlog Refinement Meeting, i criteri di accettazione di una user story che permetteranno di verificare se questa possa essere realizzata come “done”.
La Definition of Done (DoD) è la qualità del prodotto consegnato. Si tratta della lista dei criteri che permettono di decidere se una funzionalità possa essere considerata “terminata” e che possa essere consegnata alla fine dello sprint. È applicabile a tutti gli item del backlog.
La velocità di un team si basa sulle funzionalità “concluse”. È un contratto tra il team e il/la Product Owner (che rappresenta le parti coinvolte ed è la voce del cliente) e definisce chiaramente i criteri che devono essere soddisfatti affinché una user story, un’iterazione o una versione sia finita e possa essere consegnata.
Una prima versione del backlog deve necessariamente essere definita precedentemente al primo sprint per organizzare gli sviluppi poiché il product backlog serve anche come strumento di pianificazione. In funzione della velocità del team di lavoro (calcolata nello story point), gli sprint sono creati e caricati con le user story stimate nello story point. Con l’avanzare degli sprint, il backlog si arricchisce di nuovi Epic corrispondenti a un nuovo bisogno identificato, nuovi US che completano una feature già sviluppata, bug o compiti tecnici per prevenire il debito tecnico del prodotto.
Quali strumenti possono essere utilizzati per gestire un product backlog?
Un product backlog in Scrum può essere realizzato su un semplice foglio di lavoro Excel, ma alcuni strumenti ne facilitano l’utilizzo e il prosieguo delle user story, tra questi ci sono ad esempio JIR, Trello e Projectboard
