Ore vs. Dimensioni vs. Conteggi

Gli esseri umani sono scarsi nello stimare il tempo assoluto, e gli ingegneri non fanno eccezione. La ricerca sull'errore di pianificazione — la tendenza sistematica a sottostimare quanto tempo richiederanno le attività — mostra costantemente che le persone sottostimano di un fattore da 2 a 4, anche per attività che hanno già svolto. Il problema non è pigrizia o incompetenza. Il problema è cognitivo: quando immagini di svolgere un'attività, immagini il percorso ideale. Non immagini la suite di test instabile, i criteri di accettazione poco chiari, la dipendenza aggiornata la settimana scorsa o le due ore che passerai in riunioni.

Le ore invitano anche al bias di ancoraggio. Una volta che qualcuno dice "probabilmente sono circa 4 ore", ogni stima successiva orbita intorno a 4. Se la prima persona avesse detto 12, il gruppo sarebbe converguto su un numero diverso — non perché il lavoro è cambiato, ma perché l'ancora è cambiata. Le ore sembrano precise in un modo che invita a una falsa sicurezza. "Questa è un'attività da 6 ore" suona come un fatto. È una supposizione che indossa un camice da laboratorio.

La soluzione non è "migliorare nella stima delle ore". Decenni di evidenze dicono che non funziona. La soluzione è smettere di usare un'unità di misura che innesca l'errore di pianificazione in primo luogo e passare a qualcosa di relativo.

La stima relativa aggira l'errore di pianificazione chiedendo "quanto è grande questo rispetto a qualcosa che abbiamo già fatto?" invece di "quante ore ci vorranno?" Non stai prevedendo il futuro — stai confrontando.

Le scale più comuni sono le taglie (S, M, L, XL) e i numeri in stile Fibonacci (1, 2, 3, 5, 8, 13). Entrambe funzionano perché sono deliberatamente imprecise. Non c'è una differenza significativa tra un 6 e un 7, quindi la scala non offre queste opzioni. Fibonacci ti costringe in categorie, e gli intervalli tra le categorie crescono man mano che i numeri aumentano — il che corrisponde alla realtà. La differenza tra un 1 e un 2 è significativa. La differenza tra un 13 e un 15 è rumore.

La chiave per far funzionare la stima relativa sono le storie di riferimento. Scegli due o tre ticket completati che l'intero team ricorda e assegna loro delle dimensioni: "il redesign della pagina di login era un 5, la correzione dell'export CSV era un 2, l'integrazione dei pagamenti era un 13". Ora ogni nuovo ticket viene confrontato con quei riferimenti, non con una scala temporale astratta. "È più simile alla correzione CSV o al redesign del login?" è una domanda a cui gli ingegneri possono rispondere con sicurezza. "Quante ore ci vorranno?" è una domanda a cui sbaglieranno risposta.

Il metodo di stima più semplice è nessuna stima — basta contare i ticket. Se il tuo team completa circa 12 ticket per sprint e il backlog ha 15 ticket nel prossimo sprint, sai di essere sovraccarico senza stimarne nemmeno uno.

Il conteggio funziona quando i ticket sono più o meno della stessa dimensione, il che significa che funziona quando i team sono disciplinati nella suddivisione. Un ticket che dice "costruisci l'intero sistema di notifiche" e un ticket che dice "aggiungi un controllo null all'endpoint di export" non sono unità comparabili. Ma un team che scrive costantemente ticket dimensionati da mezza giornata a due giorni di lavoro — dove il ticket più grande è al massimo 3–4 volte il più piccolo — può usare il conteggio dei ticket come proxy affidabile per la capacità.

La disciplina che questo richiede è la suddivisione delle storie: scomporre il lavoro in pezzi abbastanza piccoli da avere una bassa variazione di dimensione. Non è gratis. Ma ha un beneficio collaterale che può essere più prezioso della stima stessa — ticket piccoli e ben definiti sono più facili da revisionare, più facili da testare e meno propensi a rimanere "in corso" per una settimana. Il metodo di stima premia esattamente il comportamento che vuoi dal team comunque.