Cosa la Stima Non Ti Dà

Una stima è una previsione, non un contratto. Nel momento in cui un team tratta una stima come un impegno — "hai detto che era un 5, quindi dovrebbe essere fatto entro mercoledì" — la stima smette di essere uno strumento di pianificazione e diventa un meccanismo punitivo. Gli ingegneri rispondono gonfiando le stime per proteggersi, il che rende le stime inutili per la pianificazione, il che spinge gli stakeholder a chiedere con più forza numeri "accurati", il che porta gli ingegneri a gonfiare ancora di più. Il ciclo è prevedibile e comune.

La distinzione conta soprattutto al confine tra ingegneria e il resto dell'organizzazione. All'interno del team, le stime guidano la capacità dello sprint e aiutano a identificare le settimane sovraccariche. Va bene — il team controlla il piano e può adattarlo a metà sprint. Il problema inizia quando le stime lasciano il team come promesse di consegna a vendite, dirigenti o clienti. Un "pensiamo che sia circa 13 story point di lavoro" diventa "l'ingegneria si è impegnata per tre settimane" in una presentazione che il team non vede mai.

Proteggere le stime dal diventare impegni è una disciplina del team e una responsabilità della leadership. Il team dovrebbe comunicare le stime come intervalli ("2–4 settimane a seconda di cosa troviamo nel codice legacy"), non punti. E i leader dovrebbero resistere alla pressione di eliminare l'incertezza dalle stime per far sembrare una roadmap più pulita. L'incertezza è la parte onesta.

La stima ha un costo: il tempo che il team spende stimando invece di costruire. Per la maggior parte dei team, quel costo è ragionevole — 30 minuti di stima risparmiano ore di sorprese a metà sprint. Ma il costo può crescere fino a quando la cerimonia consuma più valore di quanto ne produca.

Segnali di avvertimento che la stima è diventata uno spreco a sé stante:

• Le sessioni di stima durano più di un'ora. Se il team sta spendendo 90 minuti per stimare il lavoro di uno sprint, i ticket non sono definiti abbastanza bene per essere stimati, oppure il team sta dibattendo dettagli implementativi che appartengono alle discussioni di design, non alla stima.
• Nessuno usa le stime dopo la sessione. Se le stime vanno nel tracker e nessuno le consulta durante la pianificazione dello sprint, i controlli di capacità o le retrospettive, il team sta producendo numeri per nessuno. Smetti di stimare quei ticket e dedica il tempo altrove.
• La ri-stima è routine. Se il team ri-stima regolarmente i ticket perché lo scope è cambiato, i requisiti si sono spostati, o "ora lo capiamo meglio", la stima sta avvenendo troppo presto. Stima più tardi, quando il lavoro è meglio definito, o accetta che le stime iniziali siano approssimative e non ri-stimare.

Il principio è lo stesso che si applica a ogni pezzo di processo: se non sta creando leva, sta creando overhead. La stima dovrebbe essere economica, veloce e utile. Quando diventa costosa, lenta o ignorata, ridimensionala.

Il movimento #NoEstimates sostiene che la stima è spesso non necessaria e che i team possono prevedere la consegna usando il throughput storico — il numero di ticket completati per settimana — invece di assegnare dimensioni ai singoli ticket. L'argomento ha merito, e liquidarlo come pigrizia è sbagliato quanto trattarlo come vangelo.

La previsione basata sul throughput funziona così: se un team completa costantemente 10–14 ticket per settimana, e un progetto ha 45 ticket, la previsione è 3–5 settimane. Nessuna sessione di stima necessaria. La matematica si basa su due condizioni: i ticket devono essere suddivisi in dimensioni approssimativamente simili, e il team ha bisogno di dati storici sufficienti per stabilire un intervallo di throughput affidabile. Quando queste condizioni sono soddisfatte, la previsione è spesso più accurata di una stima bottom-up di ogni singolo ticket.

Il problema è la disciplina. I team che saltano la stima ma saltano anche la disciplina di suddivisione finiscono senza alcuna capacità di previsione — non possono stimare perché hanno abbandonato la pratica, e non possono usare il throughput perché i loro ticket vanno da fix di un'ora a epic di tre settimane. #NoEstimates senza suddivisione coerente è solo #NoInformation.

Per la maggior parte dei team, il percorso pragmatico è da qualche parte nel mezzo: stimare leggermente (S/M/L), tracciare il throughput come segnale secondario, e abbandonare completamente la stima solo quando i dati mostrano che il solo throughput è sufficiente. La scelta peggiore è stimare pesantemente e ignorare il throughput — è cerimonia massima per informazione minima.