Compilazione e gestione del backlog del prodotto

Il primo passaggio consiste nel convertire tutte le idee e le note in storie utente, che descrivono la funzionalità desiderata dall'utente finale, ovvero ciò che l'utente richiede al software, ma non i dettagli dell'implementazione, ovvero come creare il software che soddisfa tali richieste. Il titolo di ogni storia utente deve seguire il formato "In qualità di <utente>, desidero implementare la <funzionalità> in modo che <motivo>".

Come il backlog del prodotto stesso, ogni storia utente si evolverà nel tempo. Nel corso del progetto, il team assegnerà priorità e valuterà queste storie, vi aggiungerà informazioni dettagliate, le suddividerà in storie più piccole o le eliminerà completamente. Quelle che vengono introdotte negli sprint vengono implementate e fornite ai clienti.

Per ulteriori informazioni sulle storie utente, fare riferimento a Creare o aggiungere al backlog prodotto e a Storyboard un elemento di backlog di utilizzare PowerPoint.

Dopo aver convertito tutte le idee e le note in storie utente, è il momento di eseguire la stima e l'assegnazione delle priorità.

Per definizione, la stima non è precisa. Tuttavia, è possibile che l'utente raggiunga livelli migliori nella creazione di stime relativamente accurate con il tempo e la pratica e la partecipazione dell'intero team. Il primo passaggio consiste nel raggruppare il team in modo da fornire stime sugli elementi di backlog prodotto. Per eseguire la stima, il team assegna a ciascuna storia una stima di dimensione relativa con un'unità di misura astratta, denominata punto della storia.

Le stime sono indispensabili per due motivi:

1. Consentono di rispondere alla domanda "Quando avremo finito?"

2. Consentono al proprietario del prodotto di determinare la priorità di ogni elemento.

Le stime forniscono al proprietario del prodotto e al team una conoscenza del costo di una determinata storia, che, a sua volta, consente al proprietario del prodotto di classificare in ordine di priorità le storie. Più grande è la stima dell'elemento, più costosa sarà l'implementazione in termini di tempo e risorse. Pertanto, un elemento che il proprietario del prodotto potrebbe considerare molto utile, potrebbe diventare meno prioritario se ha un costo elevato.

Il team può utilizzare le tecniche di planning poker, big wall o altre tecniche per valutare il lavoro in termini di punti della storia. Per ulteriori informazioni sulle tecniche di stima e una lezione rapida in punti della storia, vedere Stimare e Pulire e stimare il backlog.

Dopo che il team ha valutato tutte le storie, è il momento di assegnare le priorità.

Tutti i backlog prodotto sono classificati in ordine di priorità in termini di valore aziendale e rischio. Il proprietario del prodotto confronta ogni elemento nel backlog rispetto agli altri per determinarne la priorità. A tale scopo, il proprietario del prodotto considera la dimensione di ciascun elemento, il relativo valore per l'azienda e tutti i rischi connessi. Gli elementi sono quindi elencati in ordine di priorità decrescente. Gli elementi con priorità alta vengono visualizzati in corrispondenza o nella parte superiore del backlog prodotto e gli elementi con priorità più bassa vengono visualizzati in corrispondenza o nella parte inferiore. I team scelgono il lavoro per lo sprint imminente tra gli elementi con priorità più elevata, in modo che gli elementi più importanti vengono completati prima.

Non tutti gli elementi nel backlog hanno la stessa dimensione. Alcune possono essere completate in uno sprint, mentre altre sono talmente estese che il team non sa esattamente cosa comportano e quando tempo sarà necessario per l'implementazione. Ciò è OK. Mano a mano che gli elementi si avvicinano alla parte superiore del backlog, il team li renderà più piccoli e più dettagliati in modo che tutti comprendano meglio il lavoro che indirizzeranno negli sprint successivi.

Così come con la stima, l'assegnazione di priorità del backlog prodotto iniziale può essere impegnativa. Come è possibile bilanciare in modo efficace le richieste in competizione delle parti interessate, tenendo allo stesso tempo in considerazione il prodotto finale, i rischi e i costi? Fortunatamente, esistono diverse tecniche che semplifica l'attività più semplice, inclusi i giochi di innovazione e il peso relativo. Per ulteriori informazioni su queste e altre tecniche vedere Pianificazione dello sprint e Pulire e stimare il backlog.

A prescindere dalla tecnica di classificazione di priorità utilizzata, è necessario ordinare il lavoro in modo da garantire che il team compili le funzionalità di maggior rilievo per l'azienda, le parti interessate e i clienti. Se non si classifica il lavoro in ordine di priorità, si aumenta il rischio di fornire storie utente con priorità inferiore anziché con priorità più alta, nonché storie utente incomplete quando vengono modificate risorse e pianificazioni.

(Per ulteriori informazioni sulla natura degli elementi di backlog, vedere Creare o aggiungere al backlog prodotto e Pianificazione Agile e iterazioni).

La pulitura del backlog prodotto, come indicato in precedenza, deve verificarsi regolarmente.

In scrum il team deve dedicare il 5-15% del tempo di ogni sprint in attività di pulitura. Il team deve comprendere ciò che viene dopo e ciò che si sta modificando in modo da poter dividere tutte le storie grandi che stanno crescendo di priorità, valutare le storie che sono state create e predisporre una progettazione e una pianificazione iniziali per le storie imminenti. Per assicurarsi che ciò accada, il proprietario del prodotto e il team devono, durante ogni riunione di pianificazione dello sprint, dedicare del tempo alla pulitura del backlog. Per ulteriori informazioni sulla pianificazione dello sprint, vedere Pianificazione dello sprint e Pianificare un'iterazione.

Nello sprint di due settimane, vorrei tenere questa riunione durante la seconda settimana. Il proprietario del prodotto ha così il tempo sufficiente per parlare approfonditamente con i clienti e le parti interessate, capire i cambiamenti nell'azienda e chiarire le storie utente e le storie nuove o che aumentano di priorità. È inoltre un momento logico durante lo sprint per iniziare a fare previsioni sui prossimi sprint. È possibile decidere quando tenere la riunione. È importante concedere il tempo sufficiente durante lo sprint per il completamento delle attività di pulitura.

Durante una tipica riunione di pulitura, il proprietario del prodotto presenta le novità, i cambiamenti e il piano per i prossimi sprint. Oltre a stimare le nuove storie e suddividere quelle che devono essere completate a breve, il team dedica del tempo nel corso di questa riunione per rivedere l'architettura corrente del sistema e pianificare o progettare le funzionalità successive. Durante questo processo, la stime della storia sono spesso cambiate e le nuove storie tendono a essere visualizzate poiché le storie più grandi sono suddivise in storie più piccole.

Questo processo sembra semplice, ma può rivelarsi difficile. Per semplificare il processo, il proprietario del prodotto deve essere preparato a rispondere a delle domande. Può verificarsi un conflitto se, ad esempio, il proprietario del prodotto sta pianificando l'esecuzione di una storia nello sprint successivo ma non può fornire la chiarezza necessaria per il team per fornire una buona stima. Se ciò accade durante le riunioni di pianificazione dello sprint, lo ScrumMaster dovrà dare istruzioni al proprietario del prodotto circa le informazioni di clienti e parti interessate che dovrà presentare al team.

Alla fine di ogni riunione di pulitura, il proprietario del prodotto deve pubblicare le modifiche alle parti interessate e ai clienti in modo da tutti possano vedere le novità e il piano di rilascio aggiornato.