La velocità del team nell’agile: come misurarla e utilizzarla (+ calcolatore gratuito)

La velocità del team è un dato di riferimento per le previsioni, non un KPI. Nel momento in cui si valutano i team in base a questo parametro, il valore risulta gonfiato.

La velocità è il numero medio di story point che un team completa per ogni sprint, calcolato sulla base degli ultimi sprint. Questa è l’intera definizione. Il suo unico scopo è quello di prevedere quanti sprint saranno necessari per portare a termine il backlog, tenuto conto del ritmo effettivo di consegna del team. Si sommano i punti rimanenti, si divide per la velocità e si ottiene una previsione. Onestamente, questa è l’unica funzione che svolge.

Qualsiasi altro utilizzo ne compromette l’efficacia. «Perché la velocità è stata inferiore in questo sprint?» trasforma ogni retrospettiva in una difesa del dato numerico. «Il Team A ha una velocità superiore rispetto al Team B» considera comparabili le calibrazioni indipendenti di due team, quando in realtà non lo sono. «Dobbiamo aumentare la velocità del 20% in questo trimestre» indica al team di far salire il dato, e il team lo farà, aumentando il volume apparente dello stesso lavoro anziché svolgerne di più. È la legge di Goodhart applicata a un ciclo di due settimane.

Un’avvertenza sincera prima di passare alle istruzioni: il Guida allo Scrum non fa riferimento alla velocità. Si tratta di una pratica comune che si sovrappone a Scrum, non di una sua regola, ed è proprio per questo che vale la pena riflettere attentamente sugli scopi per cui la si utilizza.

Come calcolare la velocità del team

Prenda i punti raggiunti in ciascuno degli ultimi tre-cinque sprint. Calcoli la media. Quella è la sua velocità.

Un esempio pratico, articolato su tre sprint:

Sprint	Story point completati
Sprint 7	21
Sprint 8	34
Sprint 9	26

Velocità = (21 + 34 + 26) diviso per 3 = 27 punti per sprint.

Se il backlog presenta ancora 210 punti, la previsione è pari a 210 diviso 27, ovvero circa 8 sprint. Poiché i valori inseriti variavano da 21 a 34, la versione più accurata è “da sette a dieci sprint”, non “7,8 sprint”. Oppure eviti i calcoli e lasci che sia la calcolatrice qui sopra a eseguire il calcolo per Lei.

Le regole che garantiscono l’attendibilità del dato: non apportare correzioni per gli sprint “eccezionali”, poiché proprio questi ultimi fanno parte del segnale che si sta cercando di livellare. Non conteggiate due volte il lavoro riportato dallo sprint precedente e non conteggiate affatto le storie parzialmente completate. Queste vengono conteggiate nello sprint in cui vengono effettivamente portate a termine. Più semplice è il calcolo, più difficile è aggirare il sistema.

La velocità si stabilizza dopo che una squadra ha lavorato insieme per tre o quattro sprint. La formazione di un nuovo team, l’adozione di una nuova storia di riferimento o un cambiamento significativo nell’organico sono tutti motivi per scartare il valore precedente e ricominciare da zero. Il valore non è una proprietà della tecnica, bensì una proprietà di quel team in quel determinato periodo di tempo. Un team che ieri ha perso due membri presenta una velocità corrispondente a quella di un team diverso.

Utilizzo della velocità per pianificare il prossimo sprint

Velocity dimostra tutta la sua utilità nella pianificazione dello sprint, e il metodo è breve:

1. Si parta dalla media mobile degli ultimi tre-cinque sprint, mai dal risultato di un singolo sprint e mai dal proprio sprint migliore.
2. Tenete conto delle variazioni di capacità già note. Due persone in congedo nel prossimo sprint? Una festività? Ridimensionate l’obiettivo in modo proporzionale prima della pianificazione, non con tono di scusa a posteriori. La velocità si basa sul team che l’ha generata, mentre il team del prossimo sprint a volte è più ridotto.
3. Impegnatevi al di sotto della media, all’incirca dall’80 al 90 per cento di essa. Selezionate le storie fino a raggiungere approssimativamente tale percentuale e lasciate un margine per il lavoro non pianificato che si presenta in ogni sprint, indipendentemente dal fatto che lo abbiate previsto o meno.
4. Fornite previsioni sotto forma di intervalli. Per qualsiasi periodo che vada oltre il prossimo sprint, indicate come limiti i vostri sprint recenti migliori e peggiori. Le parti interessate possono pianificare in base a un intervallo compreso tra “sette e dieci sprint”. Non possono invece basarsi su un numero preciso che poi si riveli errato.

Utilizzate la velocità per fare tre cose, e solo tre: prevedere una data per un ambito noto (l’ambito diviso per la velocità fornisce il numero di sprint), decidere cosa inserire nel prossimo sprint e individuare quando qualcosa è cambiato (un calo del 30% è un segnale che merita una discussione durante la retrospettiva). Ciò che non potete fare: confrontarla con i dati di un altro team, utilizzarla per valutare il team o convertirla in «ore previste per sviluppatore al giorno». Ognuna di queste azioni rappresenta lo stesso errore sotto una veste diversa.

Quanti story point per ogni sprint?

Cercare “quanti story point per sprint” costituisce un errore di categoria. Non esiste un valore standard del settore, né un numero “giusto”, né una media giornaliera per sviluppatore. La velocità (velocity) rappresenta la produttività misurata del team, e l’unica versione utile è la media mobile calcolata sugli ultimi sprint del team stesso. Quindici punti, quaranta punti, cento punti: nessuno di questi valori è giusto o sbagliato. Sono tutti calibrati in base alla story di riferimento del team.

Il grande errore: la velocità come indicatore di prestazione

La causa di fallimento più comune in assoluto: un manager interpreta il valore della velocità come un indicatore della produttività del team. Tale dato viene citato nelle riunioni di aggiornamento, poi confrontato tra i vari team e infine utilizzato come obiettivo. Nel giro di due sprint il team ha rivisto le proprie stime per far aumentare il valore: ogni story ha ora una dimensione superiore del 30% rispetto a prima e la velocità ha perso il significato che aveva in precedenza. La previsione che avrebbe dovuto fornire è ora errata.

Il secondo: il confronto tra i team. Due team che valutano lo stesso backlog ottengono valori di velocità diversi poiché utilizzano storie di riferimento diverse, ed è proprio questo il punto centrale della stima relativa. Confrontarli equivale a confrontare due termometri con punti zero diversi. I numeri non hanno lo stesso significato, e considerarli come se lo avessero compromette la calibrazione di entrambi i team.

Desidera che i calcoli vengano effettuati per Lei? Torni al calcolatore di velocità gratuito e provi a inserire i dati relativi ai Suoi sprint.

Quando effettuare una nuova stima

La rivalutazione del lavoro completato rallenta la velocità di avanzamento. La rivalutazione del lavoro riportato è l’unico caso in cui si agisce in modo corretto.

Ogni trimestre si pone la stessa domanda: «L’avevamo valutato come un 5, ma in realtà era un 13; dovremmo aggiornarlo?». L’istinto che suggerisce di rispondere affermativamente è lo stesso che vorrebbe che ogni numero fosse corretto a posteriori, ed è sbagliato. La velocità è il ritmo con cui il team, in base alla calibrazione che aveva in quel momento, ha completato il lavoro. Tornare indietro e riscrivere i punti significa riscrivere anche la calibrazione, e la previsione che prima funzionava smette di funzionare. «Il team è diventato più veloce, quindi le vecchie storie dovrebbero essere più piccole» elimina l’unico segnale che indica il miglioramento del team. «Questo 5 si è rivelato essere un 13» è un segnale di affinamento per valutare la prossima storia simile, non un’autorizzazione a riscrivere la storia di questa.

L’unico caso in cui è opportuno procedere a una nuova stima è quello del “carry-over”. Una story non è stata completata, lo sprint sta volgendo al termine e il lavoro residuo viene trasferito nell’impegno dello sprint successivo. Tale lavoro residuo è sostanzialmente diverso da quanto stimato all’inizio: il team ne ha già svolto una parte, ha individuato almeno un elemento imprevisto e ha una visione più chiara di ciò che resta da fare. Valutatelo nuovamente come se fosse un nuovo elemento, utilizzando la stima originale come verifica di plausibilità piuttosto che come vincolo.

Normalizzazione della velocità tra i vari team

La normalizzazione è per lo più un rituale SAFe volto a garantire la coerenza di un dashboard di portafoglio. Vi invitiamo a evitarla, a meno che un vostro superiore non abbia realmente bisogno di quel dashboard.

La normalizzazione consente a due o più team di concordare su uno scenario di riferimento condiviso, solitamente qualcosa del tipo “una giornata-persona di lavoro per un ingegnere medio”; pertanto, un 5 nel Team A ha lo stesso significato di un 5 nel Team B, e le loro velocità possono essere sommate. La tecnica funziona: un 5 normalizzato ha effettivamente lo stesso significato per tutti i team che lo hanno concordato. Il problema è ciò che si è sacrificato in cambio. Avete sostituito la natura relativa delle stime di ciascun team con una natura assoluta, che equivale a una stima della durata mascherata, solo per poter calcolare una media tra team che non condividono né un codice base, né uno stack, né un dominio.

Se una previsione a livello di portafoglio serve effettivamente a finanziare il lavoro (e non solo a confrontare i team), effettui la normalizzazione a livello di aggregazione: faccia in modo che la direzione del programma mantenga un moltiplicatore di punti per ciascun team, calibrato una volta sola e rivisto raramente, e lo applichi al momento dell’aggregazione dei dati. Ogni team continua a formulare le proprie stime rispetto alla propria storia di riferimento; il moltiplicatore converte la velocità del team nella «valuta» del portafoglio, e le riunioni di affinamento non ne vengono mai a conoscenza. Cosa evitare: la normalizzazione che ha inizio all’interno di un singolo team e quella effettuata per facilitare il confronto tra i team. Quest’ultima non è un caso d’uso, bensì un anti-modello con un nome accattivante.

Velocity e gli strumenti di programmazione basati sull’intelligenza artificiale

Copilot, Cursor, Claude Code. I punti non cambiano. La velocità sì, ma solo a posteriori.

La domanda ricorre in ogni team che utilizza un assistente di programmazione basato sull’intelligenza artificiale da alcuni mesi: stiamo rilasciando i prodotti più rapidamente, dovremmo quindi ridimensionare il backlog? Il valore 3 dell’ultimo trimestre dovrebbe diventare un 5 in questo trimestre? La risposta è no, poiché gli story point non hanno mai misurato l’elemento che è cambiato. I punti misurano la complessità relativa e l’incertezza; l’assistente riduce il tempo trascorso alla tastiera per una story, talvolta in modo drastico, ma la complessità rimane invariata, le incognite rimangono invariate, il rischio di integrazione e i casi limite rimangono invariati. Se ridimensionate un 5 a un 3 solo perché lo strumento ha scritto il codice standard e state nuovamente effettuando la stima in ore, state commettendo un errore.

Ciò che cambia è la velocità. Lo stesso team che consegna lo stesso tipo di lavoro con l’ausilio di un assistente produce più punti per sprint rispetto a sei mesi fa, non perché i punti siano diminuiti, ma perché il team è diventato più veloce nel trasformare i punti in codice consegnato. Questo è il numero che svolge esattamente il proprio compito e si ricalibra naturalmente nell’arco di tre o quattro sprint. Mantenete aggiornata la storia di riferimento del team, una che sia stata consegnata con gli strumenti che utilizzano attualmente, e la calibrazione terrà già conto di qualsiasi aumento di velocità esistente.

Due aspetti su cui è necessario intervenire. L’affermazione «La velocità è aumentata del 30%, impegniamoci a ottenere un ulteriore 30%» comporta un doppio conteggio del miglioramento: la media recente include già l’effetto dell’intelligenza artificiale, pertanto non è necessario ricalcolarla nuovamente. «Tutto è diventato più piccolo, rivalutiamo il backlog» è la trappola della rivalutazione di cui sopra: le storie non si sono ridotte, il team è diventato più veloce e la previsione ne tiene già conto. L’incertezza è l’ambito in cui gli strumenti sono meno d’aiuto: un assistente accelera alcune parti dell’indagine di uno [spike],/guides/agile-estimation-guide/splitting-user-stories/ ma l’aspetto che lo spike sta cercando di comprendere non è diventato affatto più semplice.

Effettuate insieme la stima in TeamRetro

L’efficacia di Velocity dipende dalla qualità delle stime su cui si basa. TeamRetro Estimations consente di svolgere il planning poker con il vostro team, in tempo reale o in modalità asincrona, in modo che i punti inseriti in questo calcolatore derivino dal giudizio dell’intero team e non dalla supposizione di una singola persona. Provi TeamRetro Estimations oppure inizi con lo strumento gratuito di planning poker.

Domande frequenti

Che cos’è la velocità del team nell’agile?

La velocità del team è il numero medio di story point che un team porta a termine per ogni sprint, solitamente calcolato sulla base degli ultimi tre-cinque sprint. Si tratta di un dato di riferimento per la pianificazione, utilizzato per prevedere il volume di lavoro che potrà essere inserito nel prossimo sprint e il tempo necessario per evadere il backlog, non di un indicatore delle prestazioni del team.

Come si calcola la velocità di un team?

Sommi i punti storia completati in ciascuno degli ultimi tre-cinque sprint e calcoli la media. Se negli ultimi tre sprint sono stati completati 21, 34 e 26 punti, la sua velocità è pari a 27. Conta solo le storie completate nello sprint in cui sono state portate a termine, oppure utilizzi il calcolatore gratuito disponibile in questa pagina per effettuare i calcoli.

Qual è una buona velocità di un team?

Una velocità stabile. Non esiste un parametro di riferimento, poiché i punti di ogni team sono calibrati in base alla propria storia di riferimento; pertanto, 15, 40 e 100 possono essere tutti valori positivi. Una buona velocità è quella su cui è possibile basare la pianificazione, non un numero che continua a salire.

È opportuno confrontare la velocità tra i vari team?

No. I diversi team calibrano i punti in base a scenari di riferimento diversi, pertanto le loro velocità non sono espresse nelle stesse unità di misura. Confrontarle equivale a confrontare due termometri con punti zero diversi. Il confronto tra team diversi spinge inoltre i team a gonfiare le stime, il che compromette le previsioni che la velocità è destinata a fornire.

E se non utilizzassimo i punti come unità di misura, ma, ad esempio, le taglie delle magliette?

È comunque possibile monitorare una produttività approssimativa, ma non è possibile ricavare un valore reale della velocità direttamente dalle taglie delle magliette, poiché le taglie non sono sommabili. Due opzioni. In primo luogo, associate le taglie a una semplice scala a punti (ad esempio XS=1, S=2, M=3, L=5, XL=8), sommate gli articoli completati in ogni sprint e considerate il risultato come una tendenza approssimativa piuttosto che come un dato preciso. Oppure, se le vostre attività hanno solitamente dimensioni simili, contate invece la produttività: il numero di attività completate per ogni sprint. Entrambe le opzioni sono meno precise rispetto alla velocità basata sui punti; pertanto, interpretatele come indicazioni di tendenza, non come valori decimali. Quando avete bisogno di una previsione reale, rivalutate il lavoro a breve termine in termini di punti. Consulti la nostra guida alle taglie delle magliette per il collegamento tra taglie e punti.

Come si procede alla rendicontazione del lavoro che non è registrato come voci quantificate?

La velocità riflette solo il lavoro che effettivamente quantificate e monitorate. I ticket di assistenza, le riunioni, le interruzioni e le correzioni di bug non specificate consumano comunque capacità; pertanto, se gran parte di tale lavoro rimane invisibile, la vostra velocità risulterà inferiore all’impegno reale del team e le vostre previsioni risulteranno ottimistiche. Due soluzioni concrete. Registrate il lavoro ricorrente non pianificato come elementi quantificati, in modo che venga incluso nella velocità come tutto il resto. Oppure riservate apertamente della capacità a tale scopo, impegnandovi a coprire circa l’80-90% della vostra media e lasciando il resto come Slack. Non attribuite punti a posteriori al lavoro invisibile solo per far sembrare il numero più alto, poiché ciò compromette la calibrazione su cui si basa la velocità.

Come gestite le rielaborazioni in Velocity?

Il lavoro di rifinitura richiede un impegno concreto, ma riclassificare una story già considerata completata compromette la velocità. Trattate il lavoro di rifinitura come un nuovo lavoro: create una nuova voce, ne valutate l’entità e la conteggiate nello sprint in cui viene completata. Non riaprite la storia originale né la rivalutate. Se le rielaborazioni continuano a presentarsi, si tratta di un segnale relativo alla qualità che merita una discussione durante la retrospettiva, non un adeguamento della velocità. La previsione rimane attendibile solo se ogni punto viene conteggiato una sola volta, nello sprint in cui il lavoro è stato effettivamente completato.

Quanti story point per sprint si considerano normali?

Non esiste un valore standard per il settore. La velocità è la produttività misurata del vostro team, ovvero la media mobile dei punti completati negli ultimi sprint. Quindici, quaranta, cento: nessun valore è giusto o sbagliato, poiché ciascuno è calibrato in base a una storia di riferimento diversa.

Quanti story point per sprint per sviluppatore?

Non calcolatene uno. Una tariffa per singolo sviluppatore trasforma nuovamente gli story point in ore mascherate e favorisce il confronto tra le persone, proprio ciò che questa tecnica è stata concepita per evitare. La velocità è un dato relativo al team, non la somma delle quote individuali.

Quanti story point ci sono in un sprint di due settimane?

Qualunque sia il numero di storie che il vostro team ha storicamente portato a termine in un sprint di due settimane, misuratelo, ma non fissatelo come obiettivo. Selezionate le storie fino a raggiungere un totale pari all’80-90% circa della vostra media recente, lasciando spazio agli imprevisti.

Qual è una buona velocità per un team Scrum?

Un sistema stabile. «La nostra velocità è adeguata?» è la domanda che mette a rischio il sistema. Nel momento in cui la velocità viene valutata, i punteggi si gonfiano e nulla viene effettivamente consegnato più rapidamente. Una buona velocità è quella su cui è possibile basare la pianificazione, non un numero che continua a salire.

Letture correlate

• Story point contro ore: perché la conversione da story point a ore rappresenta proprio quella modalità di fallimento che la velocità è chiamata a sostituire.
• Pianificazione della velocità e della capacità: utilizzare la velocità per definire un impegno realistico per lo sprint.
• Che cos’è un grafico burndown?: il modo in cui i team tengono traccia dei punti che si sono impegnati a realizzare nell’ambito di uno sprint.
• Tecniche di stima agile: dove si colloca la velocità rispetto al planning poker, agli story point e alle altre tecniche, e quale utilizzare in quali circostanze.
• Guida alla stima agile: il cluster completo dedicato alla stima.
• Planning Poker gratuito per team agili: stimare i punti su cui si basa la velocità.