A Cosa Serve la Stima

La stima svolge tre compiti, e i team che li confondono finiscono per essere frustrati con tutti e tre.

Compito 1: Comprensione condivisa. Quando un team stima insieme un ticket, il numero è un effetto collaterale. Il vero risultato è la conversazione. Un ingegnere dice "è una piccola modifica — cambiare l'endpoint e aggiornare i test." Un altro dice "aspetta, quell'endpoint è dietro un feature flag da cui dipendono altri tre servizi." Il divario tra le loro stime è il divario tra i loro modelli mentali del lavoro. Far emergere quel divario prima che il lavoro inizi vale più del numero stesso.

Compito 2: Pianificazione della capacità. Un team con 10 ingegneri e uno sprint di due settimane ha una quantità finita di lavoro che può assorbire. La stima — anche approssimativa — ti dice se stai caricando l'80% della capacità o il 140%. Senza di essa, la pianificazione dello sprint è un'ipotesi, e "ci siamo impegnati su troppo" diventa un tema ricorrente nelle retrospettive.

Compito 3: Prioritizzazione. Una funzionalità che offre valore moderato e costa un piccolo sforzo è una conversazione diversa da una funzionalità che offre lo stesso valore e costa un grande sforzo. La stima dà a product ed engineering un linguaggio condiviso per fare compromessi. Senza di essa, la prioritizzazione va a chi urla più forte.

Alcuni lavori genuinamente non possono essere stimati, e fingere il contrario produce numeri che ingannano più di quanto informino.

Un ticket che dice "indagare perché il webhook di pagamento fallisce in modo intermittente" non è stimabile. L'ingegnere non sa se la causa principale è una race condition, un timeout dell'API di terze parti, una policy di retry mal configurata o qualcos'altro. Stimarlo come "medio" assegna semplicemente un numero all'ignoranza — e ora il piano dello sprint tratta quel numero come se significasse qualcosa.

La risposta onesta è "non lo so, e ho bisogno di uno spike per scoprirlo." Uno spike è un'indagine con tempo limitato — tipicamente da mezza giornata a due giorni — il cui output non è codice funzionante ma informazioni. Dopo lo spike, il team sa abbastanza per stimare la correzione effettiva. Gli spike non sono un fallimento della stima; sono la stima che funziona correttamente ammettendo i propri limiti.

Lo stesso vale per lavori genuinamente nuovi: una nuova integrazione con un'API non familiare, una migrazione a una tecnologia che il team non ha usato, o un problema di performance senza un collo di bottiglia ovvio. Forzare una stima su questi ticket non produce informazioni utili — produce un numero che il team si sente obbligato a rispettare e un piano costruito sulla finzione.

I team che sono ossessionati dalla precisione della stima stanno ottimizzando la cosa sbagliata. Un team le cui stime sono costantemente sbagliate del 30% ma che usa la conversazione di stima per far emergere assunzioni, individuare lacune nello scope e allinearsi sull'approccio sta ottenendo più valore dalla stima di un team i cui numeri sono perfetti ma che stima in silenzio.

Il numero è un sottoprodotto. La conversazione è il prodotto. Quando due ingegneri stimano lo stesso ticket in modo diverso, quel disaccordo è informazione — uno di loro sa qualcosa che l'altro non sa, o stanno immaginando implementazioni diverse. Risolvere quel disaccordo prima che il lavoro inizi previene rilavorazioni, individua requisiti mancanti e costruisce contesto condiviso nel team.

Questo è il motivo per cui i metodi di stima che forzano la conversazione (come /learn/xp/planning-practices/planning-game, dove tutti rivelano simultaneamente) superano i metodi che non lo fanno (come una persona che annuncia un numero e chiede "vi sembra giusto?"). La rivelazione non riguarda il numero — riguarda il divario. Un ticket dove tutti mostrano un 3 è noioso. Un ticket dove una persona mostra un 2 e un'altra mostra un 8 è dove la stima guadagna il suo valore.