Gestione del Prodotto in Scrum

Un Planning Game è una riunione di pianificazione per decidere quali user story includere nella prossima iterazione o release.

Al Planning Game partecipano stakeholder di progetto, IT e aziendali. I partecipanti selezionano le user story che offrono il maggiore valore aziendale al prodotto o progetto, in base alle stime del carico di lavoro.

Il Planning Poker è un gioco di team building per raggiungere un consenso di gruppo sulla stima del carico di lavoro.

I giocatori usano carte con numeri della sequenza di Fibonacci per assegnare punti storia alle user story e stimare il carico di lavoro.

Il team deve raggiungere un consenso di gruppo su quanto tempo impiegheranno le user story o i requisiti per essere completati.

Un Product Backlog è l'elenco dei requisiti richiesti dal cliente.

Il product backlog non è un elenco di 'cose da fare', ma un elenco di tutte le funzionalità che il cliente ha richiesto.

Il team Scrum utilizza il product backlog per stabilire le priorità delle funzionalità e decidere quali implementare durante gli sprint.

In un ambiente Kanban, il Product Owner assembla e stabilisce le priorità di un backlog di elementi di lavoro da portare a termine. Il Product Owner ha la flessibilità di modificare e ridefinire le priorità del lavoro nel backlog in qualsiasi momento senza influire sul lavoro già in corso.

Migliorare, chiarire e semplificare la struttura interna del codice esistente senza influenzarne il comportamento esterno.

Non include la riscrittura del codice o la correzione di bug. Il sostantivo "refactoring" si riferisce a metodi specifici e finiti per il refactoring del codice, come l'utilizzo del metodo Extract per chiarire lo scopo di un pezzo di codice.

Refactoring viene utilizzato in Agile per mantenere la chiarezza e l'estensibilità del codice tra le iterazioni dello sprint.

Uno dei diversi tipi di stime che i team Agile utilizzano per determinare la quantità di sforzo necessaria per completare le attività del progetto.

Le attività o le storie utente vengono confrontate con attività equivalenti, completate in precedenza o con un gruppo di attività di difficoltà simile.

I team Agile spesso utilizzano una scala non numerica per confrontare le attività, come la taglia delle magliette, in cui lo sforzo dell'attività viene valutato come extra-piccolo, piccolo, medio, grande o extra-large.

I team Agile utilizzano la stima relativa per valutare il tempo e lo sforzo necessari per completare un'attività o una user story in base al tempo impiegato per completare un'attività simile.

Un singolo elemento di lavoro all'interno del product backlog. Può essere una user story, un'epic, una specifica, un bug o un requisito di modifica. Il product owner lo definisce e ne stabilisce la priorità, dando la precedenza agli elementi più urgenti o importanti.

Il membro del team Agile che rappresenta il cliente e traduce i suoi requisiti e la sua visione al team. Scrive i criteri di accettazione, stabilisce le priorità e gestisce il product backlog.

Un ciclo di sviluppo del prodotto che dura 1-4 settimane, durante il quale il team lavora su un insieme di PBI prioritizzati per creare un incremento funzionante del prodotto.

L'insieme di tutte le funzionalità e le richieste del prodotto, ordinate in base alla priorità. Il Product Owner lo gestisce e lo aggiorna costantemente.

Un'attività che il team deve completare in un determinato sprint. Dovrebbe essere abbastanza piccola da essere completata in un solo sprint.

L'insieme dei criteri che definiscono se una user story è stata completata in modo soddisfacente.

La pratica di suddividere un PBI in user story più piccole, per facilitare la gestione del lavoro e il completamento in un singolo sprint.

Un metodo di gestione del progetto che si concentra sulla consegna continua di valore al cliente, tramite iterazioni brevi e collaborative.