Stima agile: la guida completa

Il Planning Poker è una tecnica di stima agile basata sul consenso: i team votano in modo riservato, rivelano tutte le carte contemporaneamente e discutono la distribuzione dei voti fino a quando le stime non convergono.

Come condurre una sessione di Planning Poker che fornisca stime utili senza protrarsi all’infinito: preparazione, il ciclo in quattro fasi, la scelta del mazzo e una rigorosa limitazione temporale.

Gli story point misurano lo sforzo relativo, la complessità e l’incertezza del lavoro — non le ore. Come valutare l’entità di un lavoro rispetto a una storia di riferimento e le domande che mettono in difficoltà i team.

I punti di storia salgono a 1, 2, 3, 5, 8, 13 perché gli intervalli sempre più ampi riflettono l’incertezza: la scala smette di fingere che si possa distinguere un 13 da un 14. Ecco perché gli intervalli sono il punto fondamentale.

I punti storia misurano lo sforzo relativo; le ore misurano la durata: si tratta di assi diversi. Se si crea una tabella di conversione da punti a ore, si è tornati, senza rendersene conto, a stimare il tempo.

La velocità è la media dei punti storia che un team completa per ogni sprint. A cosa serve, perché smette di funzionare nel momento stesso in cui diventa un obiettivo e come garantirne l’autenticità.

Le persone non sono brave a valutare “quanto tempo ci vorrà”, ma sono brave a valutare “se una cosa è più grande di un’altra”. La stima relativa si basa su quest’ultimo principio — ed è per questo che gli story point funzionano.

Le stime iniziali presentano un ampio margine di variazione perché il lavoro è sconosciuto, non perché il vostro team non sia in grado di stimare correttamente. Cosa significa il “cono di incertezza” e come restringerlo — anziché ampliarlo.

Le epiche, le storie e le attività costituiscono tre livelli, ciascuno con tre ruoli. Che cosa rappresentano, quale di essi genera punti storia e perché attribuire punti al livello sbagliato rende la velocità un parametro privo di significato.

Confronto tra le tecniche di stima agile — planning poker, T-shirt sizing, buckets, dot voting, stima per affinità e stima “magica” — e le modalità di fallimento che ciascuna di esse nasconde.

I problemi ricorrenti che possono insorgere durante le sessioni di Planning Poker — calcolo della media delle carte, stime in ore, “velocity” utilizzata come arma, inflazione dei punti storia — e come risolverli.

I criteri di accettazione costituiscono il test di superamento o meno di una story, redatto prima dell’inizio dei lavori: i formati validi, gli esempi concreti e le differenze rispetto alla definizione di “completato”.

La definizione di "completato" consiste in una checklist condivisa da tutto il team che ogni story deve superare prima di essere rilasciata. Un esempio di tale definizione, chi ne è responsabile e in che modo essa differisce dai criteri di accettazione.

La definizione di “pronto” è la lista di controllo che indica se una story è pronta per essere inserita nello sprint. Cosa comprende una lista utile, perché la maggior parte viene ignorata e quale versione costituisce effettivamente un ostacolo.

Una storia di cui non si riesce a valutare la lunghezza è solitamente una storia che non è ancora pronta per essere pubblicata. Come capire quando è il momento di suddividerla, quali sono le linee di taglio che producono parti pubblicabili e quali invece danno solo l’impressione di farlo.

SPIDR consiste in cinque metodi affidabili per suddividere una user story: spike, percorso, interfaccia, dati, regole. Ogni linea di suddivisione: quando funziona e quando produce una suddivisione errata.

Le suddivisioni verticali generano valore; quelle orizzontali generano promesse. Perché la suddivisione per livello tecnologico ritarda la generazione di valore e come suddividere in base ai risultati per l’utente, in modo che ogni sprint produca qualcosa di concreto.

Una user story è una breve promessa di valore formulata in un linguaggio semplice. Il formato “ruolo-obiettivo-beneficio”, le tre “C”, la checklist INVEST e i casi in cui le user story non rappresentano lo strumento adeguato.

Sedici esempi di user story relativi ad autenticazione, e-commerce, dispositivi mobili, API e bug — ciascuno corredato di note, con le versioni errate riportate accanto alle rispettive revisioni, in modo da rendere evidente la differenza.

Il modello classico di user story con una scheda “copia-incolla”, le varianti da conoscere e un esempio concreto che illustra il percorso dal modello ai criteri di accettazione fino alla stima.