Velocità: a cosa serve e come calcolarla

La velocità è un dato di riferimento per le previsioni, non un indicatore chiave di prestazione (KPI). Nel momento in cui si utilizzano i team per misurarla, i valori risultano gonfiati.

La velocità è il numero medio di story point che un team completa per sprint negli ultimi sprint. Questa è l’intera definizione. Esiste per un unico scopo: prevedere quanti sprint saranno necessari per portare a termine un backlog, dato il ritmo effettivo di consegna del team. Sommando i punti rimanenti e dividendo per la velocità, si ottiene una previsione. Onestamente, questa è l’unica funzione che svolge.

Qualsiasi altro utilizzo lo snatura. «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» impone al team di far salire il dato, e il team lo farà — sovrastimando il volume dello stesso lavoro, non svolgendone di più. La legge di Goodhart, applicata a un ciclo di due settimane.

Come calcolarlo

Prendete i punti completati in ciascuno degli ultimi tre-cinque sprint. Calcolatene la media. Quella è la vostra velocità. Non tenete conto degli sprint “eccezionali”: proprio gli sprint eccezionali fanno parte del segnale che state cercando di livellare. Non conteggiate due volte il lavoro riportato dallo sprint precedente. 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 è aggirarlo.

La velocità si stabilizza dopo che una squadra ha corso insieme per tre o quattro sprint. Una nuova squadra, una nuova storia di riferimento, un cambiamento significativo nell’organico: tutti motivi per scartare il valore precedente e ricominciare da zero. Il valore non è una proprietà della tecnica; è una proprietà di questa squadra in questo periodo di tempo. Una squadra che ieri ha perso due membri presenta la velocità di ieri, ma quella di una squadra 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 tariffa 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 storia di riferimento del team.

Utilizzate quindi la velocità per fare tre cose, e solo tre: prevedere una data per un ambito noto (ambito ÷ velocità = numero di sprint); decidere cosa inserire nello sprint successivo (selezionare le storie fino a raggiungere circa l’80–90% della media recente, lasciando spazio agli imprevisti); 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.

Cosa va storto

La modalità di fallimento più comune in assoluto: un manager interpreta il valore della velocità come un indicatore di “quanto è produttivo questo 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 ora ha una stima 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 perché utilizzano storie di riferimento diverse: è proprio questo il punto centrale della stima relativa. Confrontarli è come 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.

Quando effettuare una nuova stima

La rivalutazione del lavoro completato rallenta la velocità. 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 sì è 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 che il team è migliorato. «Questo 5 si è rivelato essere un 13» è un segnale di affinamento per valutare la prossima storia simile a questa, non un’autorizzazione a riscrivere la storia di questa.

L’unico caso in cui è opportuno procedere a una nuova stima è quello del “carry-over”. Se 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’incognita 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 team

La normalizzazione è per lo più un rituale SAFe volto a garantire la coerenza di un dashboard di portafoglio. Evitela, a meno che un suo 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” — in modo che un 5 nel Team A abbia lo stesso significato di un 5 nel Team B, e che le loro velocità possano essere sommate. La tecnica funziona: un 5 normalizzato ha effettivamente lo stesso significato in tutti i team che lo hanno concordato. Il problema è ciò che si è sacrificato per ottenerlo. Avete sostituito la natura relativa delle stime di ciascun team con una natura assoluta — il che equivale a una stima della durata mascherata — solo per poter calcolare una media tra team che non condividono né un codice sorgente, 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), effettuate la normalizzazione a livello di aggregazione: fate in modo che la direzione del programma mantenga un moltiplicatore di punti per ciascun team, calibrato una volta sola e rivisto raramente, e applicatelo al momento dell’aggregazione dei dati. Ogni team continua a formulare le proprie stime in base 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, perché 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, a volte in modo drastico, ma la complessità rimane invariata, le incognite rimangono invariate, il rischio di integrazione e i casi limite rimangono invariati. Non ridimensionate un 5 a un 3 solo perché lo strumento ha scritto il codice standard e state nuovamente effettuando la stima in ore.

Ciò che cambia è la velocità. Lo stesso team che consegna lo stesso tipo di lavoro con l’aiuto 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 dato che svolge esattamente la sua funzione 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, quindi 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, ma l’aspetto che lo spike sta cercando di comprendere non è diventato affatto più semplice.

Domande frequenti

Quanti story point per sprint si considerano normali?

Non esiste un valore standard di 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?

Indipendentemente dal numero di storie che il vostro team ha storicamente portato a termine in un sprint di due settimane — misuratelo, ma non fissatelo come obiettivo. Scegliete le storie fino a raggiungere un totale pari all’80–90% circa della vostra media recente e lasciate un margine per gli imprevisti.

Qual è una buona velocità per un team Scrum?

Una velocità stabile. «La nostra velocità è adeguata?» è la domanda che mette in crisi 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.
• Guida alla stima agile — il cluster completo dedicato alla stima.
• Planning Poker gratuito per i team agili — stimare i punti su cui si basa la velocità.