Come stimare l’entità di un progetto?

I miei colleghi e io discutiamo molto su alcuni temi per cercare, attraverso la conversazione e il dialogo, di raggiungere una visione condivisa su elementi importanti delle nostre attività. Siamo un’azienda di consulenza: facciamo agile coaching e aiutiamo i nostri clienti a implementare metodologie agili all’interno della loro organizzazione, per cui è necessario riflettere sulle nostre esperienze per individuare strategie comuni e definire il nostro stile di coaching e le modalità con cui proporre certe pratiche.

Uno dei temi più dibattuti riguarda le stime, in particolare come “pesare” la complessità delle User Stories che andranno realizzate: è meglio usare i punti (User Story Points) o le ore per stimare le diverse storie?

Misure relative o assolute?

In Scrum, la stima delle User Stories assume un valore cruciale e dibattuto. La scelta tra User Story Points e ore può influenzare significativamente il processo di sviluppo e il miglioramento continuo del team.

Gli User Story Points rappresentano una misura relativa della complessità di una user story, che tiene conto di vari fattori come la quantità di lavoro, i rischi e l’incertezza. Chiaramente, con gli User Story Points posso solo valutare relativamente le storie, stabilendo ad esempio che la storia A ha una complessità tripla rispetto alla B, ma vale la metà di C. Questo non mi dice tantissimo sul tempo che poi sarà effettivamente necessario per implementarle, ma mi fornisce un’idea chiara del peso relativo tra le diverse storie e mi consente di valutare quanto “peso”, alla fine dello Sprint, saremo riusciti a implementare come team.

Personalmente non sono favorevole a usare come misura il tempo, ma qualcosa che consenta una stima scollegata dal tempo che passa, in modo da stimolare il processo di miglioramento: infatti, i punti fatti aumentano Sprint dopo Sprint… mentre il tempo no.

Le ragioni a favore degli Story Points

Oltre alla considerazione appena fatta, svariate altre ragioni spingono a favore dell’adozione degli Story Point, che possiedono alcuni vantaggi chiave. Vediamoli di seguito.

Astrazione dal tempo

Gli story points permettono al team di stimare la complessità senza legarsi direttamente al tempo. Questo è particolarmente utile per evitare il cosiddetto “effetto Parkinson”. L’effetto Parkinson, formulato nel 1995 da Cyril Northcote Parkinson, afferma che il lavoro si espande per riempire il tempo disponibile per il suo completamento: in pratica, se ho una settimana di tempo per fare un determinato lavoro, alla fine a concluderlo ci metterò proprio una settimana…

Focus sul valore

Concentrarsi sulla complessità e non sul tempo incoraggia il team a pensare al valore e alla fattibilità delle storie piuttosto che a quante ore ci vorranno per completarle.

Miglioramento continuo

Gli Story Points facilitano la misurazione della velocità del team — velocity in termini di punti completati per Sprint — che è un indicatore chiave per il miglioramento continuo. La velocità può aumentare man mano che il team diventa più esperto e migliora i suoi processi.

Usare i punti semplifica molto la gestione di questo aspetto. Se infatti il team usasse il tempo per stimare un’attività, sarebbe necessario adattare continuamente questa misura. Un po’ come un atleta che, con l’allenamento, inizia a performare meglio, il team impara a lavorare meglio e di più: se i primi tempi il team reputa che l’effort per fare una cosa sia di tot ore, dopo qualche mese, fare una cosa analoga impiega meno ore per cui si renderebbe necessaria una continua rivalutazione o semplicemente adattamento.

Con i punti è tutto più semplice: se per fare quella cosa si erano stimati tot punti di effort, dopo quattro mesi fare una cosa analoga “peserà” gli stessi punti anche se il team ci mette meno tempo, o anche lo stesso perché si è reso conto che è più difficile del previsto. Di fatto aumenta quindi il numero di cose che il team riesce a fare, ossia la somma dei punti totali per Sprint. Non cambia il peso di una data attività, che se vale 5 pt a inizio anno, pesa 5 pt anche a fine anno, ma casomai aumenta la velocità del team, che effettivamente può migliorare con il passare dei mesi, l’apprendimento dei membri del team e il loro affiatamento. Con una stima delle attività fatta per tempo-ore è tutto meno semplice e immediato.

Flessibilità

Le stime basate su Story Points sono più flessibili e possono essere adattate meglio a diversi contesti e dinamiche di team rispetto alle ore.

Perché stimare in tempo/ore, invece?

In maniera trasparente, ho dichiarato la mia preferenza per il sistema dei punti storia. Ma, per onestà intellettuale, occorre riconoscere che che stimare in ore è comunque un approccio più vicino al modo in cui siamo abituati a ragionare nella vita di tutti i giorni: dal tempo necessario per imbiancare una stanza a quello che ci vuole per rimontare il motore di una macchina.

Vediamo quindi quali sono i vantaggi della stima in tempo/ore.

Chiarezza immediata

Per alcuni team, soprattutto quelli meno esperti in Scrum, le ore possono sembrare più concrete e facili da valutare e comprendere.

Pianificazione dettagliata

Le ore possono fornire una pianificazione più semplice da collegare al piano orario (giornaliero, settimanale o di Sprint), utile in contesti dove è richiesta una visione temporale.

Controindicazioni della stima in tempo/ore

Tuttavia, usare le stime orarie può avere una serie di aspetti svantaggiosi.

Le stime in ore possono portare a una rigidità eccessiva e non permettono di gestire efficacemente le incertezze e i cambiamenti. Lavorare con stime in ore può indurre stress nel team, per le ore che passano, specialmente se le stime non vengono poi rispecchiate dal tempo realmente impiegato, influenzando negativamente la motivazione e la performance.

Misurare solo il tempo impiegato non incentiva il miglioramento delle performance e non offre una visione chiara dell’efficienza del team. Di fatto, stimare le cose in tempo-effort si lega al tempo che il team ha disponibile che per forza di cose è limitato superiormente dalla somma degli FTE del team, o anche meno se le persone, oltre a lavorare nel team, fanno anche altre cose. Non di rado team che usano il tempo come stima finiscono per mettere in lavorazione attività la cui somma oraria è maggiore delle ore disponibili, di fatto passando a una valutazione in ore logiche ossia in punti…

Le stime in ore sono spesso imprecise e non tengono conto delle variabili e incertezze intrinseche nello sviluppo software. Questo porta a discrepanze tra le previsioni e le ore effettivamente spese.

Concentrarsi sulle ore può portare a una cultura di micromanagement e di pressione per rispettare le stime temporali, piuttosto che concentrarsi sulla qualità del prodotto e sul miglioramento continuo.

Usare le ore rende difficile misurare la velocità del team, un indicatore chiave in Scrum per prevedere la capacità futura e per migliorare la pianificazione.

Per tutte queste ragioni credo che gli User Story Points siano generalmente preferibili per stimare la complessità delle User Stories in Scrum. Questo approccio non solo incentiva il miglioramento continuo del team, ma permette anche una maggiore adattabilità e un focus più orientato al valore. Tuttavia, la scelta finale dovrebbe sempre considerare il contesto specifico del team e dell’organizzazione, e potrebbe essere utile sperimentare entrambi gli approcci per determinare quale funzioni meglio nel proprio ambiente lavorativo.

Quando le stime “escono” dal team

Non di rado, usare le stime in tempo ha anche l’effetto collaterale di innescare “attenzioni” intorno al team specie se tali numeri “escono” dal team e finiscono nelle mani sbagliate, per esempio nello staff a supporto degli aspetti finanziari che inizia ad agganciarci valutazioni sui costi di progetto. Ci vuole veramente poco affinché tali numeri, da strumento di supporto del team per valutare il lavoro da svolgere nello Sprint, diventino un modo per fare il previsionale dei costi, allocando previsioni di spesa, budget e altre valutazioni economiche; tutte cose necessarie alla vita di un’azienda, ma che nella pratica spesso finiscono per essere un modo per aggiungere pressione e controllo alle persone, finendo a detrimento dell’interesse globale dell’organizzazione stessa.

Rendere pubblica la somma delle ore necessarie per svolgere un compito di fatto amplifica la frustrazione o la preoccupazione quando poi, a fine iterazione, tali numeri non corrispondono più. Usare le ore spesso amplifica la mancanza di comprensione se qualcosa non torna.

E se per il team Scrum questo non è un problema — in retrospettiva poi si cerca di capire perché i numeri non sono tornati e al prossimo Sprint si adattano le stime — per lo staff controllo invece è un problema, perché non tornano le previsioni economiche. Evidenziare questo problema spinge in avanti alla ricerca di soluzioni ancora più complesse, come il cercare strumenti più precisi per fare stime — che, per definizione, non si trovano — o di far lavorare ulteriormente a fine Sprint, per far tornare le ore effettivamente spese con i previsionali iniziali, mescolando una consuntivazione temporale con le stime.

Tutte soluzioni complicate che non agiscono sul problema a monte — calcolare il costo di progetto non è la stessa cosa che misurare lo stato di avanzamento — e ha l’effetto deleterio di impedire di avere numeri attendibili, come per esempio una velocità di Sprint attendibile, forse l’unica grandezza in grado di aiutare nel prevedere la fine del progetto.

Strumenti nuovi, approccio tradizionale

Tutti questi problemi sono comuni in molte organizzazioni che adottano Scrum e metodologie agili, ma che continuano a mantenere pratiche di gestione dei progetti più tradizionali. La difficoltà principale risiede nell’uso improprio delle stime in ore come strumento di previsione economica e di controllo dei costi.

Per affrontare questi problemi, in genere suggerisco prima di tutto di investire nella spiegazione agli stakeholder e al team dell’importanza degli Story Points e del modo in cui utilizzarli efficacemente. È cruciale che tutti comprendano che gli Story Points sono uno strumento per misurare la complessità e non il tempo.

Approccio ibrido

In definitiva, si tratta di entrare in questa ottica: utilizzare gli Story Points per la stima e la pianificazione, mentre le ore possono essere tracciate separatamente per la consuntivazione, senza che queste influenzino direttamente le previsioni economiche.

Per facilitare la transizione, si potrebbe considerare un approccio ibrido iniziale, dove si continuano a tracciare le ore per i report economici, ma si inizia a utilizzare gli Story Points per la pianificazione e la misurazione della velocità.

È essenziale dialogare con lo staff di controllo per spiegare le differenze tra stime di sviluppo, previsioni economiche e consuntivi a fine mese.

Considerare i costi nella giusta prospettiva

Quando si considera il costo di uno sprint, è fondamentale capire che i membri del team, in particolare se sono dipendenti, hanno un costo fisso per l’azienda. Questo costo non cambia se le ore sono dedicate a un progetto specifico o meno. In questo senso, lo sprint rappresenta l’utilizzo del tempo di lavoro già pagato e non è un costo aggiuntivo.

In modo provocatorio, potremmo affermare che

uno sprint non costa, ma vale una porzione del costo già sostenuto

Detto meglio,se le persone del team sono dipendenti, l’azienda le sta già pagando. Quindi lo Sprint è l’utilizzo di un tempo che sta già costando; sommando il monte ore annuale del tempo che ogni team member dichiara di poter dedicare al team, si ha un corrispettivo di tempo mensile che puoi usare  e non comprare. Questo non ha alcun collegamento con il valore delle cose che si stanno facendo.

L’idea di sommare il tempo mensile disponibile dei membri del team per determinare il “budget di tempo” utilizzabile è pratica e logica. Tuttavia, è cruciale distinguere tra il tempo come risorsa e il valore prodotto durante questo tempo. Il vero focus dovrebbe essere sul valore incrementale che il team produce durante ogni Sprint, più che sul semplice utilizzo delle ore disponibili.

Valore prodotto non è tempo speso

Gli Story Points, essendo una misura di complessità, aiutano a valutare quanto lavoro di valore può essere completato in un determinato periodo. Questo sposta l’attenzione dal costo temporale al valore reale che viene creato. In un sistema che utilizza correttamente gli story points, si misura la produttività del team in termini di valore aggiunto (user stories completate) più che di ore lavorate.

La pianificazione degli Sprint si concentra su quanto valore può essere consegnato agli stakeholder, e non su quante ore saranno impiegate. Il team può quindi adattarsi e migliorare la propria velocità, misurando il proprio progresso di efficienza in termini di Story Points completati per sprint.

La sfida principale risiede nel far comprendere allo staff di controllo che il valore prodotto durante uno sprint non si misura semplicemente in termini di ore lavorate. Uno sprint, in questa ottica, è un investimento in valore, non solo un costo di risorse temporali. Le valutazioni economiche dovrebbero quindi basarsi sulla capacità del team di generare valore più che sul semplice utilizzo delle ore di lavoro.

Conclusioni

Riconoscere che “uno sprint non costa, ma vale una porzione del costo già sostenuto” aiuta a spostare la conversazione dal costo del lavoro al valore del lavoro. Questo cambio di prospettiva può migliorare la comprensione di come le metodologie Agile, e Scrum in particolare, mirino ad aumentare il valore prodotto piuttosto che a minimizzare semplicemente il costo temporale.

Per i team di controllo, questo implica un approccio diverso nella valutazione dei progetti, focalizzato sul valore aggiunto e sull’efficienza incrementale piuttosto che su una contabilità tradizionale delle ore lavorate.