L'allineamento sulla stima: il paradosso della Story Point estimation

Narratore: Questo podcast è generato tramite voci sintetiche. È martedì pomeriggio. Il team è riunito in call per il Refinement di una nuova feature che, sulla carta, sembra piuttosto semplice.

Scrum Master: Ciao a tutti! Allora, l'obiettivo di oggi è allinearci sulla stima di questa nuova User Story. Ricordate: non stiamo parlando di ore o giorni, ma di Story Points. Dobbiamo valutare la complessità relativa, l'incertezza e lo sforzo, usando i nostri punti di riferimento abituali. Siamo pronti per il Planning Poker?

Product Owner: Sì, guardate che è una cosa veloce. Dobbiamo solo aggiungere un filtro per data di scadenza nella dashboard dei clienti e fare in modo che l'export in PDF rifletta questa scelta. In pratica, due campi e un template. Una banalità, no?

Scrum Master: Esatto! Vedete, è proprio l'esempio perfetto di una User Story ben definita. Il valore per l'utente è chiaro, l'impatto è circoscritto. Ora, procediamo con il primo round di votazione. A tre, tutti mostrano la carta. Uno, due, tre!

Senior Developer: Cinque.

Scrum Master: Cinque! Ok, Senior è su un cinque. Junior, tu cosa hai messo?

Junior Developer: Scusate, ho dato un'occhiata al codice della dashboard. Il filtro sembra semplice, ma l'export PDF usa una libreria di dieci anni fa che non supporta il paging dinamico. Per aggiungere quel filtro dovrei riscrivere l'intera logica di generazione del documento. Io direi... otto punti.

Scrum Master: Otto? Ma è un valore altissimo per un filtro! Junior, prova a confrontarlo con la Story della scorsa settimana, quella del login, che era un tre. Davvero è quasi tre volte più complessa?

Junior Developer: Non è una questione di complessità astratta, Scrum Master. È che per cambiare quel filtro devo prima aggiornare l'intera dipendenza del PDF, che però rompe l'allineamento delle colonne in tre altri report. Diventa un effetto domino.

Scrum Master: Capisco l'effetto domino, ma ricordiamoci che l'Agilità sta proprio nel gestire l'incertezza. Forse possiamo accettare un debito tecnico temporaneo per sbloccare il valore immediato?

Junior Developer: Sì, perché il login era un servizio nuovo, mentre qui dobbiamo toccare un modulo legacy che nessuno documenta da quando...

Scrum Master: Capisco il punto del legacy, Junior, ma ricordiamoci che l'obiettivo del refinement è proprio trovare il modo di semplificare. Magari c'è un workaround che non stiamo considerando per evitare di riscrivere tutto.

Senior Developer: L'unico workaround che conosco per quella libreria è pregare che il server non crashi durante la generazione del PDF. E spoiler: crasha sempre se l'export supera le dieci pagine.

Product Owner: Aspettate un attimo. Otto punti significa che non rientriamo nello Sprint. Il problema è che ho promesso al commerciale che la feature sarebbe stata online tra due settimane per l'accordo con il cliente X. Due settimane. Quindi, l'idea di otto punti... non è molto compatibile con la realtà, giusto?

Narratore: Interviene il Software Architect. Fino a questo momento si discuteva di un filtro, ora si discute di scadenze commerciali.

Software Architect: Guardate, se vogliamo ottimizzare il valore dei punti, potremmo scomporre la feature. Creiamo una Story per il filtro, una per l'interfaccia e una per l'export PDF. In questo modo, frammentando la complessità in micro-task, possiamo abbassare la percezione del singolo blocco. Se assegniamo due punti a ogni pezzo, l'insieme sembra più gestibile, anche se il totale resta lo stesso.

Senior Developer: O potremmo semplicemente dare un punto a tutto. Faremmo felice il management, il Product Owner dormirebbe tranquillo e noi continueremmo a fare quello che facciamo sempre: l'overtime. L'ho fatto nel duemilaquindici con il modulo fatture. Avevamo stimato tutto a uno. Alla fine abbiamo consegnato, ma ho dovuto riscrivere il kernel del report mentre ero in vacanza a Riccione.

Software Architect: Scherzi a parte, Senior, il punto è che l'approccio incrementale ci permetterebbe di mappare l'impatto tecnico senza spaventare gli stakeholder con un numero come otto. Se lo chiamiamo 'Ottimizzazione del modulo di output', passa come miglioramento qualitativo, non come riparazione di un danno.

Junior Developer: Ma se lo scomponiamo così, ogni micro-task avrà una dipendenza dall'altra. Non stiamo riducendo l'impegno, stiamo solo moltiplicando il numero di ticket da spostare sulla board.

Product Owner: Esatto! Più ticket significa che vedremo più progressi ogni giorno. Visualmente, per me e per il cliente, l'avanzamento sarà molto più fluido.

Junior Developer: Ma se lo chiamiamo in un altro modo, il lavoro da fare resta lo stesso, no? Non è che cambiando il nome della Story il codice legacy si scrive da solo.

Product Owner: Junior, apprezzo la tua... precisione, ma nel mondo reale l'importante è che il ticket sia chiuso entro la data X. La semantica della stima è secondaria rispetto al delivery.

Scrum Master: Ma non possiamo fare così! I punti devono riflettere la realtà tecnica per poter calcolare la Velocity del team! Se mentiamo sui punti, l'intero framework Agile crolla!

Narratore: A questo punto, entra nella call il CTO.

Chief Technology Officer: Ciao ragazzi, sento che c'è un po' di tensione sulla stima. Guardate, dobbiamo cambiare prospettiva. Non vediamo i punti come una misura dello sforzo, ma come una misura della visione di valore. Questa feature è strategica per il time-to-market del cliente X. Pertanto, l'allineamento non deve essere tecnico, ma strategico.

Junior Developer: Quindi... mi sta dicendo che non importa se il codice è legacy e difficile da modificare, ma che dobbiamo comunque metterci pochi punti perché è importante per l'azienda?

Chief Technology Officer: Esattamente. È un esercizio di pragmatismo evolutivo. Se definiamo la feature come 'tre punti', stiamo dichiarando che l'organizzazione è capace di assorbire questa complessità in modo efficiente. È una questione di mindset, Junior. Innovazione significa anche saper allineare le stime agli obiettivi di business.

Software Architect: Esattamente, CTO. Sto proprio ragionando in termini di 'astrazione del valore'. Possiamo considerare i tre punti come un investimento in scalabilità procedurale: accettiamo l'inefficienza immediata per garantire l'allineamento con il business target.

Senior Developer: L'astrazione del valore è un termine bellissimo. Quasi poetico. Peccato che il compilatore non legga la poesia, preferisce i tipi di dato coerenti.

Chief Technology Officer: Senior, apprezzo il tuo pragmatismo, ma in questa fase di trasformazione digitale dobbiamo imparare a navigare nell'astrazione. È l'unica via per scalare l'organizzazione. Vedi, Architect, questo è lo spirito. Trasformare un vincolo tecnico in un'opportunità di allineamento. È questo che chiamo leadership tecnologica: saper navigare tra le necessità del codice e le esigenze del mercato.

Senior Developer: Sì, l'unico problema della leadership tecnologica è che non compila.

Scrum Master: Beh... se l'approccio è strategico, allora possiamo registrarlo come un 'allineamento di valore'. In questo caso, tre punti possono andare bene per non bloccare il flusso dello Sprint.

Product Owner: Perfetto! Tre punti. Mi sembra un numero molto più onesto e sostenibile. Grazie a tutti per la collaborazione, siamo davvero un team allineato!

Senior Developer: Ottimo. Ci vediamo sabato mattina in ufficio, allora.

Narratore: La stima è stata fissata a tre punti. Il team ha raggiunto l'allineamento strategico. La realtà tecnica, invece, è rimasta esattamente dove era: in un modulo legacy del duemilaquindici.