Stimare non è indovinare: è un esercizio collettivo di riduzione dell'incertezza. Ecco i principi e le tecniche che abbiamo imparato per costruire un processo affidabile.
C'è una dinamica che chi lavora su progetti software conosce bene: il meeting di stime che finisce per diventare una negoziazione. Da un lato, abbiamo chi ha bisogno di numeri per fare un'offerta o pianificare una roadmap; dall'altro, il team operativo, che sa che quei numeri sono fondamentalmente aleatori e lo dice, a volte con un "tanto metto i numeri a caso" che chiude la discussione prima ancora di iniziarla.
Non è cinismo, è la risposta razionale di chi percepisce il processo come un “contratto” travestito da metodo: i numeri diventano impegni, l'incertezza viene vissuta come incompetenza, e chi stima si trova a dover "vendere" una cifra invece di ragionare su un problema.
Per me, che arrivo dal design, il tema delle stime è sempre stato un territorio poco battuto, qualcosa che i PM più esperti sapevano fare. È stato confrontarmi con loro a Buildo a farmi capire che si trattava principalmente di un problema di metodo e che non c’era una risposta assoluta. Da lì sono nate la curiosità e la necessità di approfondire. Mi sono stati subito consigliati due libri, che forse a molti sono già noti: Software Estimation: Demystifying the Black Art di Steve McConnell e How to Measure Anything di Douglas Hubbard, e per me si è accesa una luce su qualcosa che davo per inevitabilmente opaco.
Quello che segue raccoglie ciò che, studiando e sperimentando, ha fatto la differenza per noi. Alcune le abbiamo trovate nei libri, altre le abbiamo capite sul campo: riflessioni su come inquadrare il problema, tecniche concrete da portare nei meeting, e qualche considerazione su cosa cambia quando si comincia ad avere dati storici su cui appoggiarsi. Chi legge non troverà una risposta definitiva su come si stima, ma qualche strumento in più per affrontare il momento con più metodo e meno stress.
Il punto da cui parte quasi tutta la letteratura sul tema, McConnell lo ripete più volte, è una distinzione che sembra ovvia ma in pratica viene ignorata costantemente: una stima non è un impegno.
Una stima è una previsione basata sulle informazioni disponibili in un dato momento. Un impegno è una promessa di un risultato. Confondere i due genera un effetto perverso: il team impara a sottostimare per non sembrare incompetente, o per non deludere le aspettative, e chi riceve la stima la usa come scadenza fissa. Quando la realtà è diversa, ovvero sempre, scattano frustrazione e sfiducia.
Una cosa che ci ha aiutato è rendere esplicita questa distinzione prima ancora di iniziare a parlare di numeri. Non "quanto ci vorrà?" ma "cosa sappiamo oggi, e quanto siamo incerti su quello che non sappiamo ancora?" Cambiare la domanda cambia il clima del meeting: si smette di difendere un numero e si comincia a ragionare insieme su un problema.
Hubbard ridefinisce la misurazione in un modo che all'inizio sembra filosofico ma poi risulta molto pratico: misurare non significa trovare la risposta esatta, significa ridurre quantitativamente l'incertezza. Non devi sapere quanto ci vorrà. Devi saperne un po' di più rispetto a prima.
Questo cambia la domanda che si fa in un meeting di stime. Invece di "Qual è il numero giusto?", la domanda diventa "cosa ci renderebbe più certi di quello che stiamo stimando?" A volte la risposta è una spike tecnica. A volte è recuperare i dati di un progetto simile. A volte è semplicemente scomporre meglio lo scope.
Il punto è che l'incertezza non è un problema da nascondere o da fingere di non avere, è l'informazione più utile che puoi portare in un meeting.
Uno degli insight più utili che abbiamo trovato in Hubbard è questo: i dati per stimare meglio sono quasi sempre più accessibili di quanto pensiamo. Nei timesheet dei progetti passati, nelle WBS, nei tracciamenti Jira, nella memoria del team.
Il problema non è (sempre) la mancanza di evidenze, è che non siamo abituati a cercarle prima di stimare. L'intuizione individuale è più rapida e meno scomoda di un confronto con la realtà. Ma è anche molto meno affidabile. Passare dall'intuizione al confronto "a cosa assomiglia questa cosa che abbiamo già fatto?" è uno dei cambiamenti più utili che si possano fare.
Le stime diventano più accurate quanto più sono granulari. Una feature grande è quasi impossibile da stimare bene. Le stesse ore totali, distribuite su dieci sotto-attività, vengono stimate molto meglio, perché la scomposizione stessa ti obbliga a capire cosa stai davvero stimando. Spesso è proprio in questo passaggio che emergono le parti di lavoro che nessuno aveva considerato: "chi fa la code review?" "c'è da aggiornare la documentazione?" "questo richiede un allineamento con il team di design?"
C'è però un effetto collaterale che vale la pena nominare: quando si scompone bene, i numeri tendono a crescere. È un effetto del bias della stima minima: tendenzialmente non scenderemo mai sotto una certa soglia per una singola attività, anche la più piccola. Quando quelle soglie si moltiplicano per tutte le sotto-attività, il totale sale. Non è da ignorare né da correggere a monte, ma è qualcosa che il PM deve tenere in considerazione quando raffina le stime finali prima di portarle all'esterno.
Una cosa che ci ha cambiato il modo di gestire i meeting è stata smettere di trattare le divergenze come un problema da risolvere in fretta. Se qualcuno stima 4 ore e qualcun altro 20, fare la media e andare avanti è la strada più rapida, ma quasi sempre quella meno utile.
Le discrepanze sono informazione. Segnalano che due persone hanno capito scope diversi, hanno presente rischi diversi o hanno esperienze diverse con quella tecnologia. La domanda giusta è: "Cosa avete visto di diverso?" La discussione che segue è quasi sempre quella che porta alla stima più utile, e fa emergere assunzioni implicite che altrimenti resterebbero nascoste fino a metà progetto.
Prima di entrare nel vivo delle stime, può valere la pena fare un rapido esercizio: immagina che il progetto sia già concluso e che le cose siano andate male. Chiedi al team "cosa è successo?" Liberare la mente dall'ottimismo obbligatorio, ovvero quello che porta a stimare lo scenario migliore come se fosse lo scenario probabile, ci permette di evidenziare i rischi che nessuno vuole nominare ad alta voce. E se quei rischi influenzano le stime, meglio saperlo prima.
Le stime devono essere riviste man mano che il progetto avanza. Non perché le prime fossero sbagliate, ma perché con il progredire del lavoro si accumulano informazioni che semplicemente non esistevano all'inizio.
Una stima fatta all'offerta è basata su un certo livello di conoscenza dello scope. Una stima fatta a metà progetto è basata su qualcosa di molto più solido. Aspettarsi che la prima regga fino alla fine significa ignorare tutto quello che nel frattempo abbiamo imparato sul progetto. Una delle prime cose che ho capito affiancando i PM in Buildo è che le restime sono una parte integrante del processo di facilitazione delle stime, che non si esaurisce mai nel primo meeting. Ovviamente non significa rifare tutto da capo a ogni iterazione: l'idea è concentrarsi solo sulle attività su cui sono emerse informazioni nuove (un requisito che si è chiarito, un rischio che si è concretizzato, uno scope che è cambiato o anche solo averci messo le mani direttamente). Restime selettive mantengono i meeting snelli e non appesantiscono le settimane con un rituale che finisce per sembrare burocratico.
Come si fanno concretamente le stime in un meeting? Esistono diversi format che aiutano a strutturare il momento, ognuno con i suoi punti di forza e i suoi contesti d'uso ideali. Non c'è una risposta unica, la cosa più utile è conoscerli e scegliere quello più adatto al tipo di progetto, alla maturità del team e alla fase in cui ci si trova. Qui ve ne suggerisco due che usiamo tuttora in Buildo e che riteniamo molto efficaci, più un piccolo bonus, una tecnica trasversale che ho trovato particolarmente utile che puoi applicare dentro qualsiasi format per far emergere le stime in modo indipendente e privo di bias.
Il T-shirt sizing è utile quando si vuole capire l'ordine di grandezza di un set di feature prima ancora di discutere ore o giorni, o anche al posto delle ore e dei giorni stessi. L'idea è semplice: invece di assegnare numeri, si assegna una taglia (XS, S, M, L, XL) ragionando per complessità relativa. Questa feature è più grande o più piccola di quella? È una L o una XL?
Il valore di questo approccio non sta nella precisione, ma nell'allineamento e nella capacità di gestire l'incertezza in modo onesto. Nelle fasi iniziali di un progetto, quando le informazioni sono ancora poche, fingere una precisione numerica finisce per nascondere l’incertezza. Usare le taglie è un modo per riconoscere esplicitamente che il livello di conoscenza non permette ancora numeri precisi, e procedere comunque in modo strutturato. Prima di usare le taglie, il team deve concordare cosa significano "grande" o "piccolo" in quel contesto specifico (come in tutti i meeting di stime, è fondamentale fissare regole comuni all'inizio). Rendere esplicita questa calibrazione collettiva evita che ognuno stia usando un righello diverso.
Funziona bene nelle fasi iniziali di un progetto, quando le informazioni sono ancora poche e fingere una precisione numerica sarebbe fuorviante. Ma funziona altrettanto bene negli sprint planning: è veloce, semplice da capire per tutto il team, e ha il vantaggio di togliere il nervosismo che spesso accompagna i numeri. Quando non si discute di "8 ore o 12 ore", ma di "è una M o una L?", il clima del meeting cambia e si arriva a una stima condivisa con meno attrito.
L'approccio evidence-based parte da una critica al modo in cui si stima di solito: guardiamo una nuova feature e chiediamo "quanto ci vuole?” Il risultato sono numeri basati su sensazioni e conoscenza personale, difficili da giustificare e facili da contestare e soprattutto, che non inquadrano davvero l'incertezza e la complessità che abbiamo davanti, ma le spostano sotto il tappeto.
La differenza fondamentale di questo metodo è che si fa un confronto con cose che abbiamo già fatto. Invece di chiederti "quanto ci vorrà?", la domanda diventa "a cosa assomiglia questa cosa nella nostra storia?" Se l'anno scorso abbiamo costruito una feature simile in 35 ore, e questa è leggermente più complessa ma non radicalmente diversa, possiamo ragionare da lì e non inventare un numero. Ancorare la stima a qualcosa di reale aiuta a quantificare il non conosciuto e a renderlo gestibile con interventi azionabili: so che questa feature assomiglia a qualcosa che ci ha preso tre settimane, e so quanto quella stima si era discostata dalla realtà.
C'è un aspetto che all'inizio può sembrare controintuitivo, ovvero che l'unità di misura non è importante. Potremmo usare ore, giorni, punti story o qualsiasi altra unità. Quello che conta è la coerenza del confronto: se la feature A vale "5" e la feature B è il doppio più complessa, allora vale "10". La relazione tra i numeri è ciò che li rende utili, non il numero in sé. Perché? Perché quello che stai davvero misurando non è "quante ore ci vorranno esattamente", ma quanto sei lontano dall'ignoto e questo si misura per confronto, non in assoluto.
In Buildo abbiamo cominciato a costruire un archivio di dati storici (WBS dei progetti passati, tracciamenti delle feature, log dei tempi effettivi) e a usarli come base di confronto nei meeting. È un approccio che richiede un investimento iniziale: i dati vanno raccolti e strutturati, e ci vuole tempo prima che l'archivio sia abbastanza ricco da essere utile. Ma quando il confronto con dati reali diventa possibile, cambia anche la dinamica del meeting: è più difficile contestare un'evidenza che un'impressione, e questo riduce la tensione che spesso caratterizza questi momenti.
Dopo aver dedicato un momento di allineamento sullo scope da stimare, ogni membro del team assegna in modo segreto e in silenzio un valore alla feature (ore, giorni, intervalli, size...), e, a chiamata, tutti rivelano contemporaneamente la propria stima. Come detto prima, l'obiettivo non è fare la media: è capire perché chi ha stimato 4 ore e chi ne ha stimate 16 hanno visto cose diverse.
Il meccanismo della rivelazione simultanea serve a ridurre il bias di ancoraggio: quell'effetto per cui il primo numero detto in una stanza influenza tutti quelli successivi. Se le carte si rivelano insieme, non c'è un'ancora, e ognuno porta la propria lettura indipendente del problema.
In pratica, il Planning Poker funziona meglio quando le divergenze sono grandi. Se tutti stimano più o meno lo stesso, si può procedere. Se c'è chi stima 2 e chi stima 13, quella distanza è il segnale che vale la pena esplorare: quasi sempre nasconde un'assunzione implicita sullo scope, una dipendenza tecnica che qualcuno conosce e qualcun altro no, o una parte di lavoro che non era stata considerata da tutti. Il numero finale è quasi secondario rispetto alla conversazione che si è aperta.
Tornando al developer che mette i numeri a caso: il problema, quasi sempre, non è la mancanza di competenza. È la mancanza di un processo che renda la stima qualcosa di diverso da un'opinione personale sotto pressione.
Quello che abbiamo imparato sia dalla letteratura che dalla pratica è che le stime diventano più affidabili quando diventano un esercizio collettivo di riduzione dell'incertezza. Quando il team non deve "sapere" la risposta giusta, ma ragionare insieme con i dati che ha.
Il numero alla fine c'è ancora. Ma è il risultato di un processo, non il punto su cui ci si scontra.
Steve McConnell, Software Estimation: Demystifying the Black Art (Microsoft Press, 2006)
Douglas Hubbard, How to Measure Anything (Wiley, 2014)
Giorgia è designer in Buildo. Ha allargato il suo sguardo alla gestione dei progetti, alla ricerca utente e alla facilitazione, anche per diventare una designer migliore.
Stai cercando un partner affidabile per sviluppare la tua soluzione software su misura? Ci piacerebbe sapere di più sul tuo progetto.
