Story Point normalizzati in SAFe – come e perché?

SAFe4 propone che gli Story Point all’interno dello sviluppo prodotto siano standardizzati tra i diversi team. A tal fine, SAFe offre un metodo per stimare già nel primissimo Sprint con gli Story Point. Dal punto di vista di Scrum, questo approccio appare inizialmente incoerente con l’idea degli Story Point. Per risolvere questa contraddizione, esaminiamo l’idea più da vicino.

Cosa sono esattamente gli Story Point?

Gli Story Point sono, in breve, un’unità di misura arbitraria per quantificare lo sforzo di un Backlog Item. Dovrebbero aiutare gli sviluppatori a pianificare meglio la propria capacità – e al Product Owner, a comprendere cosa è raggiungibile nelle prossime settimane e mesi. Così si possono ad esempio prevedere date e portata di un Release.

Un ulteriore beneficio viene proposto da Mike Cohn: se si conosce la Velocity e i costi mensili di un team, si possono effettuare stime dei costi per i Backlog Item. Così si può ottimizzare la redditività dello sviluppo. Ad esempio, un Backlog Item può apparire antieconomico una volta noti i costi. Così il Product Owner può decidere tempestivamente se una Story deve essere rielaborata o completamente scartata.

SAFe riprende questa idea nel concetto WSJF: le Feature con il miglior rapporto costi-benefici dovrebbero essere privilegiate.

La cosa più importante affinché un tale approccio possa funzionare è che tutti i coinvolti abbiano la stessa comprensione degli Story Point. Poiché gli Story Point possono significare cose diverse per team diversi, bisogna essere cauti quando si considerano i valori al di fuori del team.

Cosa sono gli Story Point normalizzati?

In SAFe l’unità di sviluppo per il prodotto è un Agile Release Train (ART), un „Team of Teams“.

Così come è importante in Scrum che tutti i coinvolti nel team comprendano uno Story Point allo stesso modo, è altrettanto importante in SAFe che tutti i coinvolti nell’ART comprendano uno Story Point allo stesso modo.

Se i team interpretassero gli Story Point in modo diverso, il Product Manager riceverebbe stime completamente differenti a seconda di quale team ha stimato un Item. Le stime risultanti sarebbero dal punto di vista del business completamente inutilizzabili. L’intero processo di stima sarebbe inutile e le stime senza valore.

Per questo SAFe propone che, così come nel team Scrum è necessaria una comprensione comune degli Story Point, anche i singoli team nell’ART necessitino di una comprensione comune degli Story Point per stimare in modo sensato.

Perché gli Story Point individuali per team non sono una buona idea?

In SAFe tutti i team nell’ART condividono un unico Program Backlog centrale e comune. Questo Program Backlog consolida tutte le attività dell’ART, indipendentemente da quale team effettivamente assumerà il lavoro in seguito.

Un concetto chiave dell’agilità è che il lavoro dovrebbe essere indipendente dalla persona, poiché la specializzazione porta all’ottimizzazione locale.

Dal punto di vista Lean è spesso meglio che un team più lento inizi subito a lavorare, piuttosto che aspettare il team più veloce per cose importanti.

Soprattutto quando più team collaborano, un team più lento può spesso già consegnare una parte del valore prima che il team più veloce diventi disponibile per partecipare. Così si riduce il tempo complessivo di consegna e l’impegno del team più veloce fino al completamento finale.

Se gli Story Point differiscono tra i team, ogni singolo Backlog Item deve essere stimato da ogni singolo team, fino a capire quale team potrebbe finire quando. Questo è naturalmente possibile, ma significa uno spreco e un overhead massicci.

Se invece gli Story Point sono normalizzati tra i team, serve una sola stima di un solo team. Guardando poi la Velocity dei singoli team, si vede rapidamente e semplicemente quanto tempo ci vorrebbe.

Un ulteriore beneficio degli Story Point normalizzati è: se il Team A ha bisogno del supporto del Team B per rispettare una scadenza importante, il Product Owner del Team B sa immediatamente quanto il Team B dovrebbe rimuovere dal proprio Backlog per assumersi le Story del Team A: poiché non è necessaria una nuova stima, non si verificano né ritardi né sforzi per la stima.

Come normalizza esattamente SAFe gli Story Point?

Nel primissimo Program Increment l’ART è nuovo. Né i singoli team, né le persone nell’ART, hanno mai lavorato esattamente in questa configurazione. I team si trovano nella „Storming Phase“ – come l’ART stesso.

Ciò a sua volta significa: i Working Agreement non sono ancora chiari. La DoD è un ideale vago che non è mai stato testato nella pratica. Ovunque possono nascondersi ostacoli. A seconda di come procede lo sviluppo prodotto, anche l’ambiente di lavoro è probabilmente nuovo e sconosciuto. Tutti si trovano su un punto bianco della mappa – ogni stima è leggere i fondi di caffè.

Un possibile approccio sarebbe ora discutere insieme quale Story scegliere come riferimento, come definire i punti, quanti punti assegnare alla Story di riferimento – e poi lavorare da lì. Questa discussione porterà ad ulteriori discussioni, che non rappresentano alcun valore dal punto di vista del cliente.

SAFe evita questo approccio e propone quanto segue: Stima Relativa

Nel primissimo PI Planning si inizia con il team che seleziona l’Item più piccolo dal proprio Backlog e gli assegna un „1“. All’Item successivo per grandezza si assegna un „2“, e ci si muove utilizzando una serie ispirata ai numeri di Fibonacci (1,2,3,5,8,13,20,40,100): abbiamo un Item della stessa dimensione di uno conosciuto? Se sì, riceve lo stesso numero – se è il più grande finora, riceve un numero adeguato. Se non abbiamo un buon riferimento e dobbiamo fare un salto, „3“ sarebbe almeno il doppio di „1“, e „8“ almeno il doppio di „3“ ecc. Così, attraverso un procedimento molto semplice senza conoscenze precise, si può formare una stima di ciò che il team ha davanti.

Naturalmente è pura supposizione e i valori sono piuttosto imprecisi. Ma poiché non abbiamo ancora valori empirici, questo approccio è valido quanto qualsiasi altro. La cosa più importante è che i team discutano delle Story riguardo a „Cosa“, „Perché“ e potenziali rischi.

Come si calcola la Velocity con gli Story Point normalizzati?

Per ribadirlo ancora una volta: nel primo Program Incremento non abbiamo la minima idea di quanti Story Point un team riesca effettivamente a completare. Dato che però abbiamo stime in PT, SAFe propone il seguente approccio nel primo PI Planning:

Sappiamo quanti membri ha il nostro team. Sappiamo anche quanti giorni in un’iterazione prevediamo di venire al lavoro (naturalmente non si sa quando ci si ammalerà – il rischio resta).

Una tipica iterazione SAFe dura 2 settimane di calendario, ha quindi 10 giorni lavorativi. Questo numero può essere moltiplicato per il numero di membri del team:
Capacity di Base = 10 * Membri del Team

Da questo sottraiamo i giorni in cui i membri del team non sono presenti:
Capacity Adattata = Capacity di Base – (Festività * Membri del Team) – (giorni di assenza individuali)

Da questo togliamo ancora il 20 percento – perché pianificare al 100 percento di utilizzo porta sempre al disastro!
Velocity Iniziale = Capacity Adattata * 0.8

Ecco un esempio:
Il Team Trolls è composto da 6 sviluppatori. Nella prossima iterazione c’è un giorno festivo e Toni deve sbrigare una faccenda personale venerdì.

Capacity di Base = 106 = 60 SP
Capacity Adattata = 60 SP (Base) – 16 SP (Festività) – 1 SP (Assenza) = 53 SP
Velocity Iniziale = 53 SP * 80 percento = 42 SP

Il Team Trolls pianificherebbe quindi l’Iterazione 1 con 42 Story Point. Se i numeri delle Story non tornano esattamente, è sempre meglio restare un po’ al di sotto piuttosto che sovraccaricarsi. I Trolls potrebbero quindi decidere di entrare nella prima iterazione con 39 SP.

Cosa succede nel tempo con gli Story Point normalizzati?

Nella prima iterazione abbiamo semplicemente tirato a indovinare. Indovinare è meglio di niente. E dopo entra in gioco Inspect+Adapt. Forse i Trolls hanno imparato che si fanno strada nel Backlog come un coltello caldo nel burro. Naturalmente la volta successiva prenderebbero qualche Story Point in più. Forse i Badgers hanno imparato che devono fare molto per gli altri team (come ad esempio il trasferimento di conoscenze). In futuro non prenderebbero più così tanti Story Point.

Così potrebbe svilupparsi la Velocity dell’ART nel tempo:

Come vediamo in questo esempio, i team utilizzano l’Inspect+Adapt individuale e controllano la propria Velocity. Il Product Manager riceve regolarmente feedback per adattare di conseguenza la pianificazione complessiva del prodotto e gli obiettivi PI (nonché eventualmente gli obiettivi di Release).

La ristima di Backlog Item precedentemente stimati non è più necessaria. Quando si presentano nuovi temi, le Story „Done“ possono essere usate come riferimento per stimare i futuri Backlog Item in modo coerente con gli Item esistenti e passati. Il legame con il giorno-persona scompare.

Attenzione con gli Story Point normalizzati

Gli Story Point non sono una metrica di business! Nemmeno la Velocity. Sono metriche di pianificazione semplificative che minimizzano lo sforzo di pianificazione e allo stesso tempo forniscono sufficiente fiducia nella fattibilità.

Queste metriche nell’ART sono soggette alle stesse limitazioni che hanno nello Scrum a singolo team. I seguenti antipattern devono essere evitati.

In nessun caso si deve:

• Considerare le stime come „corrette“. Sono – e restano – stime.

• Misurare il progresso sulla base degli „Story Point consegnati“. I prodotti utilizzabili sono la metrica primaria del progresso!

• Confrontare i team in base alla loro Velocity. La Velocity non è una metrica di performance!

• Ottimizzare la struttura dell’ART in base ai valori di Velocity. Un ART è un sistema adattivo altamente complesso!

• Cercare di mantenere la Velocity costante/in crescita. La pianificazione della capacità è minimizzazione del rischio. È soggetta alla realtà. La Velocity è solo un indicatore che aumenta l’affidabilità della pianificazione!

Quando si dovrebbero applicare gli Story Point normalizzati?

La normalizzazione degli Story Point risolve un problema che senza scalabilità non esiste affatto. Risponde alla domanda „Cosa succede se altri team lavorano a questa Story?“ Per questo la comprensione di uno Story Point deve essere uniforme oltre i confini del team.

Così nell’ART i Backlog Item possono essere spostati tra i team in modo relativamente semplice, per massimizzare il valore complessivo del prodotto consegnato invece dell’utilizzo dei singoli team.

Fino a quando non sono disponibili informazioni migliori, con un benchmark molto semplice e la stima relativa si può ottenere una buona panoramica. Dalle Story completate si possono poi scegliere Story „stimati adeguatamente“ e intuitive come riferimento per il futuro. Non ci sono ristime. Il legame inizialmente semplicemente assunto tra Story Point e giorni-persona scompare in brevissimo tempo. Questo deve accadere affinché gli Story Point restino coerenti tra i team.

Anche per la pianificazione iniziale della Velocity utilizziamo, in assenza di informazioni migliori, la regola molto semplice dell’80 percento del tempo disponibile“. Non appena la prima iterazione è conclusa, utilizziamo il risultato reale come riferimento per il futuro e ci adattiamo. Nell’arco di poche iterazioni si scioglie anche la correlazione della Velocity con la capacità temporale. Anche questo deve accadere affinché la Velocity possa essere utilizzata come strumento di pianificazione nell’ART in modo coerente e sensato.

Nell’ART è ancora più difficile che nello Scrum a singolo team resistere alla tentazione di valutare i team in base alla Velocity. L’RTE ha il compito importante di garantire l’integrità degli Story Point, bloccando tutti i tentativi (solitamente da parte del management) che potrebbero snaturare gli Story Point o la Velocity.