Stima agile: la guida completa
Una guida pratica alla stima agile: user story, planning poker, story point, velocità e le tecniche che si rivelano efficaci quando una user story si rivela più complessa di quanto sembrasse.
Le stime falliscono nei modi più comuni: numeri che assumono significati diversi a seconda delle persone, sessioni che superano i tempi previsti, previsioni di cui nessuno si fida. La soluzione raramente consiste in una formula migliore. Si tratta piuttosto di una visione condivisa da tutto il team e di stime considerate come previsioni piuttosto che come impegni che possono essere utilizzati contro di voi.
Questa guida illustra gli elementi che si dimostrano efficaci nella pratica: le user story, il planning poker, gli story point, la velocità e le tecniche che continuano a funzionare quando una story si rivela più ampia di quanto sembrasse inizialmente. Quando sarete pronti a eseguire una stima con il vostro team, effettuate la stima in TeamRetro: planning poker con votazione privata, mazzi riutilizzabili e story point finali che si sincronizzano direttamente con il vostro backlog.
Il Planning Poker è una tecnica di stima agile basata sul consenso: i team votano in modo riservato, rivelano tutte le carte contemporaneamente e discutono della 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.
La stima in story point misura lo sforzo relativo, la complessità e l’incertezza del lavoro, non le ore. Come effettuare la stima rispetto a una storia di riferimento e le domande che mettono in difficoltà i team.
I punti di storia aumentano di 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 cruciale.
I punti storia misurano lo sforzo relativo; le ore misurano la durata. Si tratta di due assi diversi. Se create una tabella di conversione da punti a ore, sarete tornati, senza rendervene conto, a stimare il tempo.
Scoprite cos’è la velocità di un team nell’agile, come calcolarla e come pianificare gli sprint tenendone conto, oltre a un calcolatore di velocità gratuito.
Le persone non sono molto 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 effettuare stime accurate. Cosa significa il “cono di incertezza” e come ridurne l’ampiezza, anziché ampliarla.
Le epiche, le storie e le attività costituiscono tre livelli, ciascuno con tre ruoli. Che cosa sono, quale di essi genera punti storia e perché attribuire punti al livello sbagliato rende la velocità un parametro privo di significato.
Una guida pratica alle tecniche di stima agile: planning poker, story point, t-shirt sizing, stima per affinità e velocità, e quando utilizzare ciascuna di esse.
I motivi ricorrenti per cui le sessioni di Planning Poker possono andare male (calcolo della media delle carte, stime in ore, “velocity” utilizzata come arma, inflazione degli story point) e come risolvere ciascuno di essi.
I criteri di accettazione costituiscono il test di superamento o fallimento 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 lista di controllo a livello di team che ogni story deve superare prima di essere rilasciata. Un esempio di definizione di “completato”, chi ne è responsabile e in che modo essa si differenzia dai criteri di accettazione.
La definizione di "pronta" è la lista di controllo che indica se una story è pronta per lo 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 portata è solitamente una storia che non è ancora pronta per essere pubblicata. Come capire quando è il momento di suddividerla, quali sono le linee di divisione 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 un risultato concreto.
Una user story è una breve promessa di valore espressa in un linguaggio semplice. Il formato "ruolo-obiettivo-vantaggio", le tre "C", la checklist INVEST e i casi in cui le user story non rappresentano lo strumento adeguato.
Sedici esempi di user story commentate relative ad autenticazione, e-commerce, dispositivi mobili, API e bug, con le versioni errate affiancate alle loro revisioni, in modo che la differenza risulti evidente.
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.
Cosa si intende per "taglie delle magliette", come condurre una sessione e come convertire le taglie S/M/L in story point, oltre a quando è preferibile ricorrere al planning poker.