Il Product Backlog è l’unica fonte di compiti svolti dal Team Scrum. È un elenco di funzionalità e miglioramenti del Prodotto pianificati. La sua forma è modificabile e non tutti i compiti inclusi nel Product Backlog saranno completati. Evolvono durante le discussioni con gli Stakeholder. Viene anche costantemente migliorato. Ciò significa che più ci si avvicina alla scadenza, più un compito diventa dettagliato.
Il Product Backlog è il più grande dei Scrum Artifacts. Riflette lo stato del lavoro su un Prodotto in relazione all’Obiettivo del Prodotto. D’altra parte, quando il lavoro su un Prodotto è completato, il suo Backlog diventa un elenco completo dei compiti svolti dal Team Scrum per creare il Prodotto. Tuttavia, non contiene soluzioni tecniche dettagliate.
Il Product Backlog viene creato durante le riunioni del Product Owner con gli Stakeholder. Il Product Owner è l’unico proprietario e la persona responsabile di questa fonte di compiti.
Il linguaggio aziendale caratterizza le voci nel Product Backlog. In altre parole, descrivono il valore del Prodotto dal punto di vista degli Stakeholder.
Le descrizioni dei compiti incluse nell’elenco dei compiti necessitano di coerenza e chiarezza. Contengono funzioni e miglioramenti del Prodotto solitamente presentati sotto forma di User Stories a cui dedichiamo un’entrata separata. Qui menzioneremo solo che si tratta di descrizioni di funzionalità parziali del prodotto che rispondono alle domande sui seguenti aspetti:
L’ordine dei compiti inclusi nel Product Backlog cambia man mano che il Prodotto si sviluppa. Lavorando su di esso, il Team Scrum modella e migliora le sue funzionalità. In caso di ostacoli, le azioni implementate consentono a tutti di riflettere e definire future soluzioni adeguate, e queste cambieranno anche in base a ulteriori ostacoli imprevisti. Pertanto, non esiste un ordine chiaro e definito delle azioni, tutto è modificabile. Il miglioramento del Product Backlog è finalizzato al suo continuo aggiornamento e preparazione per i prossimi compiti. Per questo motivo, è continuo.
I compiti con una scadenza lontana sono tipicamente grandi, generici complessi. La loro descrizione non contiene dettagli, ma solo un abbozzo di funzionalità che dovrebbe essere realizzata. È anche possibile trovare tra di essi compiti che non termineranno mai.
Le voci nel Product Backlog possono presentare soluzioni alternative. E anche le idee del Cliente che possono diventare obsolete, non redditizie o per qualche altro motivo non entrano mai nella fase di implementazione. Ecco perché il Product Backlog è talvolta scherzosamente chiamato “lista dei desideri del Cliente”.
Un altro motivo per i cambiamenti nella forma del Product Backlog è ridefinire le soluzioni. A volte si scopre che un certo problema è già stato risolto mentre si creava un’altra funzionalità del prodotto. Oppure la funzionalità prevista è diventata ridondante a causa di cambiamenti in altre soluzioni.
Una delle attività fondamentali durante il miglioramento del Product Backlog è dividere i compiti contenuti nel Product Backlog in parti. Grazie a questo, l’abbozzo generale di funzionalità è presentato sotto forma di unità più piccole, più dettagliate e precisamente definite.
I compiti progettati per una realizzazione più vicina diventano più dettagliati. Diventano anche più piccoli, contenendo dettagli delle soluzioni. I dettagli emergono durante lo sviluppo del Prodotto. E grazie alla conoscenza dello stato attuale del Prodotto e delle attuali aspettative degli Stakeholder, il Product Owner completa i compiti imminenti con la loro descrizione, ordine e dimensione. Poi, seleziona i compiti meglio descritti per il prossimo Sprint Backlog.
Durante il lavoro su un Prodotto, il Product Owner modifica e dettaglia il Product Backlog in collaborazione con il Team di Sviluppo. Seguendo le indicazioni del Product Owner, durante la Pianificazione dello Sprint il team seleziona le funzionalità da implementare dal Product Backlog. Vengono quindi spostate nel Sprint Backlog e suddivise in compiti da completare. I compiti spostati nel Sprint Backlog sono descritti in linguaggio tecnico, che è il più utile per gli Sviluppatori.
La dimensione del compito è una metrica importante dal punto di vista del Team di Sviluppo. La sua corretta stima diventa particolarmente critica quando si selezionano le User Stories dal Product Backlog allo Sprint Backlog.
Il Team di Sviluppo impara nel tempo a stimare correttamente il tempo e lo sforzo necessari per completare una specifica User Story. Questo è espresso in giorni, ore-uomo o Story Points e fornisce una stima di un valore chiamato Team Velocity.
Il Product Backlog è un elenco di compiti continuamente migliorato che porta all’Obiettivo del Prodotto. Il contenuto del Product Backlog è solitamente espresso sotto forma di User Stories. E più breve è il tempo rimanente per completare un compito, più:
Il Team Scrum si prende cura dei compiti. Il Product Owner gestisce e modifica il Product Backlog.
Se ti piace il nostro contenuto, unisciti alla nostra comunità di api laboriose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.
Diverse eventi più piccoli compongono uno Sprint in Scrum. Gli Sprint, a loro volta, formano…
I destinatari sempre più spesso si rivolgono ai materiali video. Le forme scritte diventano meno…
La scrittura pubblicitaria è diventata una professione estremamente popolare negli ultimi tempi. Ci sono sempre…
Hai mai la sensazione che la giornata sia troppo corta per fare tutto ciò che…
Che cos'è il software? Quali sono i tipi e i metodi di distribuzione? Rimanendo in…
Presentare e comunicare i risultati della ricerca è probabilmente una delle abilità più cruciali (e…