L’idea di un sistema alternativo alle stime è nato ufficialmente nel 2002 quando Woody Zuill, Vasco Duarte e Neil Killick, inizialmente tramite i post sui propri blog e poi sui social network, hanno dato vita al movimento NoEstimates.

L’idea che accomuna i tra agilisti è che tramite piccoli incrementi di lavoro, rilasciati il più rapidamente possibile, si ottiene facilmente un prodotto rilasciabile. In più, mantenendo uniforme questo flusso di lavoro, cade il bisogno di fare alcuna stima sul progetto.

Come si raggiungono gli obiettivi di NoEstimates?

Prioritizzare, non stimare

Quando si stima le funzionalità di un progetto, è inevitabile che l’effort che ne risulta entri nelle decisioni di business. I manager infatti saranno più propensi a richiedere per prime le User Story più semplici perché rappresentano vittorie facili. In questo modo però si riduce il valore del prodotto percepito dall’utente.
Piuttosto, i manager dovrebbero essere guidati a prendersi carico di un’attività continua di prioritizzazione delle funzionalità, basate sul valore effettivo per il business. Solo dopo di ciò si può pensare al modo più veloce ed efficace di consegnare valore all’utente.

Rendere costante il flusso

Nel mondo agile circola una famosa citazione del matematico John von Neumann che recita così: “There’s no sense in being precise when you don’t even know what you’re talking about.” Perché spendere intere giornate lavorative a stimare sulla base di supposizioni spesso lontane dalla realtà?

Certo, per saltare la fase delle stime bisogna avere un’idea alternativa efficace che consenta di controllare il progetto. NoEstimates si basa su un concetto di mantenere il ritmo di lavoro costante e fare previsioni sui dati di performance raccolti. Questo principio nasce dall’idea che si trova in Lean e Kanban di limitare il WIP: diminuisce la varianza ed il rischio, e di conseguenza aumenta la predicibilità.

L’attività di creare storie tutte il più possibile uniformi, consente di controllare il ritmo di lavoro su un progetto. Più questo ritmo è costante, più diventa facile fare previsioni sul futuro. Ad esempio, se sul nastro di una catena di montaggio passassero sempre quattro telai dello stesso modello di auto ogni ora, si potrebbe facilmente fare previsioni su quanti telai finiti si potranno produrre a fine giornata.
Viceversa, se nella prima ora arrivassero sei telai di una berlina di lusso, nella seconda un telaio di un’utilitaria, nella terza due telai di un furgone, fare una previsione credibile sarebbe un azzardo.

In ogni caso, al di là della dimensione delle User Story effettivamente raggiunto, quello che importa davvero è che la loro distribuzione statistica rimanga costante nel tempo, ad esempio evitando di prendere in carico tutte le storie più grandi all’inizio del progetto e alla fine tutte quelle più piccole.

User Story uniformi

Come ed entro quali limiti si può rendere uniformi le User Story? La dimensione giusta dipende dal livello di controllo che si vuole sul progresso della User Story stessa. Più questa sarà piccola e più sarà controllabile. Il più delle volte è desiderabile avere un controllo di tipo giornaliero sul progresso: per questo è consigliabile che le User Story abbiano una dimensione massima di una giornata.
Se non è richiesto un livello di controllo così preciso e puntuale, si può optare per User Story della durata di 2-3 giorni.

Oltretutto più piccole sono le User Story, più frequenti saranno gli incrementi di valore, con loop di feedback più ravvicinati, maggiori tempi di reazione e una notevole riduzione dei rischi.

Per rendere uniformi le User Story, queste devono essere di tipo INVEST:

I (Independent): le User Story deve essere autoconsistente e totalmente indipendente dalle altre. Deve poter essere staccata da un rilascio senza che questo abbia un impatto sul resto delle funzionalità.
N (Negotiable): finchè non fanno ufficialmente parte di un’iterazione le User Story dovrebbero poter essere modificate e riscritte
V (Valuable): una User Story deve rappresentare valore reale per l’utente.
E (Essential): ogni User Story deve essere veramente necessaria perchè un prodotto possa essere considerato rilasciabile
S (Small): le User Story non dovrebbero essere così grandi da renderle difficile da gestire. Dovrebbero invece avere la dimensione giusta per essere facilmente comprensibili e sviluppabili in un periodo di tempo breve.
T(Testable): le User Story devono contenere le informazioni necessarie per poter essere testate autonomamente.

La scomposizione in User Story deve essere JIT. Il che significa creare User Story INVEST solo nel momento in cui realmente serve, ossia quando si decide che è il momento di prendersi carico di una Feature per implementarla.

Prevedere piuttosto che stimare

NoEstimates usa essenzialmente il concetto di “previsione”, abbandonando quello di “stima”, questo perché si basa sull’evidenza empirica. Ossia: si può stimare un attività di cui non si ha alcuna esperienza pregressa, consci del valore approssimativo di questa stima. Oppure si può fare una previsione empirica basata su dati rispondenti alla realtà, proprio perché storicamente verificati. NoEstimates promuove questa seconda visione.

Per fare previsioni accurate a qualsiasi livello NoEstimates mette a disposizione entità con un diverso grado di granularità:

User Story: storie INVEST durata mezza giornata o una giornata in modo che siano subito evidenti eventuali colli di bottiglia
Features: sono l’equivalente delle Epic in Scrum, ossia storie non ancora analizzate nel dettaglio e di dimensioni eccessive per poter essere gestite semplicemente. Per questo devono essere ulteriormente scomposte storie di tipo INVEST.

Sfruttando il fatto che User Story e Features vedono il progetto da prospettive diverse, è possibile fare ragionamenti a diversi livelli. Ad esempio è possibile determinare quante User Story è possibile rilasciare mediamente in una settimana, calcolandone il Cycle Time medio (User Story Velocity), ma anche quanto tempo ci vuole a rilasciare mediamente una Feature (Feature Velocity).

La User Story Velocity saprà determinare quando sarà pronta una Feature, mentre la Feature Velocity dirà quando sarà finito il progetto.

Misurare il progresso

Per poter avere una misura veritiera del progresso è necessario misurarlo giornalmente e non basarsi su milestone intermedie. Solo in questo modo si riceveranno feedback quando ancora il costo del cambiamento è accettabile.
Quale misurazione dà la percezione del progresso? Noestimates utilizza il concetto di Running-­Tested-­Stories (RTS), Le Running-­Tested-­Stories sono l’equivalente del concetto di “working software” dell’Agile Manifesto. Una User Story può considerarsi chiusa solo se può essere consegnata al cliente per un utilizzo in produzione. Questo implica un’efficace applicazione della Definition Of Done, che saprà dare un’inequivocabile definizione al concetto di “fatto”. Contando le RTS rilasciate settimanalmente si ha una misura veritiera del progresso.

Requisiti flessibili

L’idea alla base dei requisiti flessibili è di chiedersi continuamente se le funzionalità richieste sono davvero essenziali per il rilascio del progetto.
Questo vale sia a livello di Feature che a livello di User Story. In prima analisi bisogna capire se tutte le Feature nel backlog sono ancora valide e necessarie. In caso contrario, si andrà a staccare quella specifica Feature dal rilascio.
Lo stesso ragionamento vale per tutte le User Story delle Feature considerate importanti: data una Feature, è proprio necessario sviluppare tutte le User Story che la compongono?

Rolling Wave Forecast

Il rolling wave forecast è uno scenario che riflette il futuro. In base ai dati in possesso si fa una speculazione su quelli che possono essere gli eventi che accadranno e quindi la situazione risultante da tali eventi. Un po’ come si fa nel mondo finanziario.
Piuttosto che consegnare al committente un Gantt con il dettaglio delle attività, NoEstimates produce la visualizzazione che rappresenta in un certo momento la situazione più realistica del progetto.
Questo dà al committente una visione reale del progresso e informazioni utili per prendere decisioni. Il committente potrà quindi accettare la previsione del progetto e rimandare qualsiasi decisione alla previsione successiva, oppure richiedere modifiche e quindi rivedere la visione di progetto.