La Stima Minima Utile

La maggior parte dei team investe troppo nella precisione delle stime. Discutono per dieci minuti se un ticket vale 5 o 8 — una distinzione che non ha alcun impatto sulla pianificazione dello sprint e ancora meno sulla consegna. Il tempo speso a discutere sulla granularità è tempo non speso a comprendere il lavoro.

Tre dimensioni — small, medium, large — coprono la stragrande maggioranza delle esigenze di pianificazione. Un ticket small è un lavoro ben compreso che un ingegnere può completare in un giorno o meno. Un medium richiede da uno a tre giorni con una certa complessità o incognite. Un large richiede più di tre giorni e probabilmente deve essere suddiviso prima che qualcuno inizi.

Tutto qui. Se il tuo team riesce a ordinare i ticket in questi tre gruppi in modo coerente, hai informazioni sufficienti per pianificare uno sprint, individuare settimane sovraccariche e identificare ticket che necessitano di ulteriore discussione. Il valore marginale di suddividere "medium" in 3, 5 e 8 è reale per alcuni team — ma la maggior parte dei team non ne ha bisogno, e la complessità costa più dei guadagni in precisione.

Inizia con S/M/L. Se dopo alcuni sprint scopri che la tua pianificazione necessita costantemente di una risoluzione più fine — magari i ticket large variano troppo, o stai facendo impegni esterni che richiedono previsioni più precise — passa a Fibonacci o alle taglie. Ma fai di questa una decisione basata su evidenze, non una decisione basata su ciò che un framework ti ha detto di fare.

S/M/L non funziona quando qualcuno al di fuori del team ha bisogno di più di "all'incirca quanto lavoro è questo?" Tre situazioni ti spingono verso una stima più granulare:

Impegni esterni. Quando un team di vendita deve dire a un cliente "la funzionalità X sarà rilasciata nel Q3," il team di ingegneria deve stimare con una risoluzione sufficiente a supportare quella data. S/M/L non può distinguere tra "tre settimane" e "tre mesi." Le stime su scala Fibonacci combinate con dati storici di velocity possono farlo — non perfettamente, ma abbastanza bene da fornire un intervallo piuttosto che un'alzata di spalle.

Budget e organico. Un team di prodotto che decide se finanziare il Progetto A o il Progetto B deve confrontare i loro costi. "Il Progetto A vale 40 story point e il Progetto B 90" è un input approssimativo ma utile. "Il Progetto A ha alcuni medium e il Progetto B ha più large" non lo è.

Pianificazione delle dipendenze. Quando il lavoro del Team A è bloccato finché il Team B non completa un prerequisito, entrambi i team hanno bisogno di una precisione di stima sufficiente per coordinare le tempistiche. "Finiremo da qualche parte nei prossimi uno o due sprint" non è abbastanza quando un team a valle sta programmando il proprio lavoro in base alla consegna.

In tutti e tre i casi, l'investimento in precisione si ripaga perché qualcuno sta prendendo una decisione basata sulla stima. Se nessuno sta prendendo una decisione — se le stime finiscono in un tracker e nessuno le guarda — risparmia tempo.

La minaccia più grande per una stima onesta è l'ancoraggio: il primo numero pronunciato ad alta voce distorce ogni numero successivo. Se il tech lead dice "penso che sia circa un 3," l'ingegnere junior che stava pensando 8 si mette in dubbio e dice 5. Il team converge su un numero che riflette la voce più forte, non la comprensione collettiva.

Planning Poker risolve questo meccanicamente. Tutti stimano simultaneamente e rivelano allo stesso tempo. Non c'è ancoraggio perché non c'è un primo numero. Lo spread — il divario tra la stima più alta e quella più bassa — è il segnale. Un 3 unanime significa che il team è d'accordo e si va avanti. Una divisione tra 2 e 13 significa che due persone stanno immaginando lavori fondamentalmente diversi, e quella conversazione deve avvenire prima che qualcuno scriva codice.

La stima asincrona estende questo ai team distribuiti. Invece di riunirsi in una stanza, gli ingegneri inviano stime in modo indipendente in una finestra temporale, con i voti nascosti finché tutti non hanno inviato. Il beneficio anti-ancoraggio è lo stesso; la logistica si adatta ai team che coprono fusi orari o non possono giustificare riunioni sincrone per ogni batch di ticket.

Entrambi gli approcci condividono lo stesso principio: la stima funziona meglio quando le opinioni si formano in modo indipendente prima di essere condivise. Qualsiasi metodo che permetta al numero dell'ingegnere senior di influenzare la stanza prima che gli altri si siano impegnati con la propria stima sta lasciando informazioni sul tavolo.