Il cono di incertezza nella stima agile

La prima stima è sempre quella peggiore — e questa è una caratteristica intrinseca del lavoro, non un difetto del team. Il “cono di incertezza” è il motivo per cui non si dovrebbe più pretendere un unico dato numerico per qualcosa che nessuno ha ancora iniziato a realizzare.

Il “cono” è un’osservazione semplice dalle conseguenze significative: all’inizio di un progetto, il divario tra la stima e la realtà è enorme, e si riduce man mano che si acquisiscono nuove conoscenze. Barry Boehm ha individuato questa forma nei dati relativi ai costi del software; Steve McConnell le ha dato il nome. Se rappresentata graficamente nel tempo, assume la forma di un cono: ampia a sinistra, dove si conoscono meno informazioni, e si restringe fino a convergere in un punto a destra, dove il lavoro è quasi completato e non vi è più nulla che possa andare storto.

Perché è importante ai fini della stima

La maggior parte delle difficoltà legate alla stima deriva dal richiedere una stima puntuale proprio nella parte più ampia del cono. Qualcuno chiede «quanto tempo richiederà il nuovo sistema di fatturazione?» prima ancora che sia stata scritta una sola riga di codice, riceve come risposta «circa tre mesi» e la considera un impegno vincolante. Il cono indica che, in realtà, tale durata si colloca tra le sei settimane e i nove mesi — e fingere il contrario non fa altro che rimandare la delusione a un momento successivo.

Questo è il motivo per cui l’agile stima la dimensione relativa anziché fissare scadenze precise. Gli story point e il planning poker non contrastano il “cono” — lo accettano. Una rapida valutazione relativa («questo è più grande di ciò che abbiamo consegnato nello sprint precedente») rappresenta il massimo livello di precisione onesto disponibile nelle prime fasi, e la velocità trasforma tale valutazione in una previsione con un intervallo di valori, anziché in una falsa promessa.

Come restringere il cono

Il cono si restringe quando si eliminano le incognite — non quando si aggiunge margine di sicurezza. In ordine di efficacia:

• Lo spike è l’incognita più rischiosa. Uno spike con un limite di tempo consente di acquisire informazioni, che sono l’unica cosa in grado di ridurre effettivamente l’intervallo di variabilità.
• Affinate il progetto finché non ci saranno più domande. Una storia sulla quale il team continua a porre domande si trova nella parte più ampia del cono; criteri di accettazione ben definiti la spingeranno verso destra./guides/agile-estimation-guide/acceptance-criteria/
• Suddividetelo. Le storie più piccole si trovano più in basso nel cono: ogni parte è ben chiara, quindi ogni stima è più precisa rispetto a un’unica stima complessiva.
• Rivalutate la situazione quando avete appreso qualcosa. Rivalutare man mano che il campo si restringe è un atteggiamento onesto; farlo per raggiungere un obiettivo non lo è.

Il cono non è una scusa per indugiare

La lezione errata è: «Tutto è incerto, quindi raddoppiate ogni stima». L’aggiunta di margini di sicurezza sposta l’intero cono verso l’alto senza restringerlo: si tratta comunque di una supposizione, solo che è pessimistica. La risposta corretta a un cono ampio consiste o nel risolvere l’incertezza (individuare un picco, affinare, suddividere) oppure nel comunicare onestamente l’intervallo e impegnarsi a ricalcolare le stime.

Domande frequenti

Che cos’è il “cono di incertezza”?

Il “cono di incertezza” descrive come l’intervallo di una stima sia più ampio all’inizio di un lavoro e si restringa man mano che il lavoro procede e le incognite vengono risolte. Nelle fasi iniziali, una stima può presentare uno scostamento significativo in entrambe le direzioni; quando il lavoro è ben compreso, l’intervallo si restringe fino a convergere sul risultato effettivo.

Chi ha coniato il concetto del “cono di incertezza”?

Tale modello fu osservato per la prima volta da Barry Boehm nei primi anni ’80 come relazione tra software e costi; in seguito, Steve McConnell lo denominò “cono di incertezza” e ne diffuse l’uso nell’ambito dell’agile e della stima dei costi del software.

In che modo il “cono di incertezza” si applica alla stima agile?

È per questo motivo che l’approccio agile si limita a stimare le dimensioni relative, anziché fissare date precise sin dall’inizio. Gli story point e il planning poker partono dal presupposto che le stime iniziali siano approssimative, sacrificano una falsa precisione a favore di una rapida valutazione relativa e procedono a nuove stime man mano che il “cono” si restringe attraverso il raffinamento, gli spike e il lavoro consegnato.

Come si fa a ridurre il “cono di incertezza”?

Non lo si gonfia: si risolvono le incognite che lo rendono ampio. Si individua il punto più rischioso, si perfeziona la narrazione finché non ci sono più domande, la si suddivide in modo che ogni parte sia comprensibile e si effettua una nuova stima una volta appreso qualcosa. Il cono si restringe quando l’incertezza viene eliminata, non quando il numero viene gonfiato.

Letture correlate

• Stima relativa vs assoluta — perché il dimensionamento relativo resiste alla prova del cono.
• Suddivisione delle user story — spike e suddivisioni: le mosse che consentono di acquisire le informazioni necessarie a restringere l’intervallo.
• Velocity — trasformare una stima iniziale e approssimativa in una previsione con un intervallo di valori.
• Guida alla stima agile — il cluster completo dedicato alla stima.
• Planning Poker gratuito per i team agili — ottenga la rapida valutazione relativa richiesta dal “cono”.