Velocity nello sviluppo software: come misurare la velocity agile nel 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

La velocity (sviluppo software) è lo strumento di previsione più semplice del lavoro agile: si somma il lavoro che un team ha terminato in uno sprint, si fa la media su più sprint e si sa più o meno quanto il team potrà prendere in carico la volta successiva. L’idea nasce dall’Extreme Programming ed è oggi una pratica standard in Scrum e negli altri framework iterativi, ma è anche uno dei numeri più usati male nella gestione dell’ingegneria.

Usata bene, la velocity trasforma una riunione di pianificazione in una breve discussione basata sui dati. I problemi iniziano quando qualcuno la trasforma in un obiettivo: le stime crescono e dopo uno o due trimestri il numero non significa quasi più nulla. Le aziende che acquistano servizi di product engineering orientati ai risultati guardano quindi la velocity accanto alle metriche di delivery e di prodotto, non da sola, perché una velocity stabile non dice se il lavoro rilasciato ha spostato un KPI di business.

Di seguito trovate la formula con un esempio calcolato su sei sprint, una previsione di rilascio da riutilizzare, un confronto tra velocity, capacità, throughput e metriche DORA, e gli errori che trasformano la velocity in una metrica di vanità – compresi quelli nuovi introdotti dagli strumenti di coding con IA nel 2026.

Che cos’è la velocity nello sviluppo software?

La velocity nello sviluppo software è la quantità di lavoro che un team agile completa in un’iterazione, misurata nelle stesse unità relative che il team usa per stimare – per lo più story point (stime relative di sforzo, complessità e incertezza invece che ore). Conta solo il lavoro che soddisfa la Definition of Done del team, cioè la checklist condivisa che stabilisce quando un elemento è davvero finito. Il numero serve a prevedere quanto lo stesso team potrà completare nelle iterazioni future.

La velocity è una misura empirica: registra ciò che è successo invece di prevedere ciò che dovrebbe succedere. Il valore della velocity sta nell’andamento su più sprint, non nel singolo sprint. Un team che ha completato 30, 34 e 32 punti negli ultimi tre sprint di due settimane ha una velocity di circa 32 punti per sprint, e quel numero ha senso solo per quel team, con la sua scala di stima, la sua codebase e la sua Definition of Done.

Il concetto è nato alla fine degli anni ’90 nell’Extreme Programming, dove i team usavano la quantità di lavoro terminata nell’ultima iterazione («yesterday’s weather», il meteo di ieri) per pianificare la successiva. Il libro di Mike Cohn Agile Estimating and Planning ha poi reso popolare la velocity insieme agli story point. La Scrum Guide ufficiale non richiede affatto la velocity; dice solo che le prestazioni passate e la capacità del team orientano la quantità di lavoro selezionata nello Sprint Planning.

Velocity di sprint e velocity del team

La velocity di sprint è il numero di punti completati in uno sprint specifico, mentre la velocity del team è la media su diversi sprint recenti. La velocity di sprint è un dato; la velocity del team è il numero di pianificazione. Pianificare su un solo sprint è rischioso, perché uno sprint può essere falsato da ferie, da un incidente in produzione o da una story insolitamente grande chiusa l’ultimo giorno.

Quali unità si possono usare per misurare la velocity?

Gli story point sono l’unità di velocity più comune, ma va bene qualsiasi unità coerente di lavoro completato. La scelta conta meno della sua stabilità nel tempo.

• Story point: stime relative di sforzo, complessità e incertezza, spesso su una scala simile a Fibonacci (1, 2, 3, 5, 8, 13).
• Giorni o ore ideali: stime di sforzo senza interruzioni, più facili da spiegare agli stakeholder ma più spesso lette come impegni di tempo.
• Numero di elementi: story o ticket completati per sprint, un approccio che funziona bene quando il lavoro è suddiviso in elementi di dimensioni simili.
• Taglie a T-shirt convertite in numeri: S, M e L associate a valori fissi, un compromesso per i team alle prime armi con la stima.

Contare elementi invece di punti elimina il rituale della stima e si comporta come un throughput. Funziona però solo se il team suddivide sistematicamente il lavoro in pezzi piccoli e confrontabili.

Come si calcola la velocity nello sviluppo software agile?

Per calcolare la velocity nello sviluppo software agile, sommate gli story point di tutti gli elementi che in uno sprint hanno soddisfatto la Definition of Done, poi fate la media di quel totale sugli ultimi tre-cinque sprint di uguale durata. La formula è: velocity = somma degli story point completati negli sprint considerati ÷ numero di sprint considerati.

1. Fissate la durata dello sprint. Usate iterazioni della stessa durata, ad esempio due settimane, altrimenti gli sprint non sono confrontabili.
2. Contate solo il lavoro finito. Un elemento conta quando soddisfa la Definition of Done: sviluppato, revisionato, testato e accettato. Gli elementi parzialmente completati valgono zero.
3. Sommate i punti per sprint. Sommate le stime di tutti gli elementi completati; quel totale è la velocity dello sprint.
4. Fate la media su più sprint. Calcolate una media mobile degli ultimi tre-cinque sprint per attenuare il rumore.
5. Comunicate un intervallo, non un numero solo. Annotate il valore recente più basso e quello più alto accanto alla media, perché è la dispersione a rendere oneste le previsioni.

La tabella seguente mostra un esempio calcolato per un team di cinque ingegneri che lavora in sprint di due settimane.

Una media mobile degli ultimi tre sprint (35, 21 e 33) dà una velocity di circa 30 punti. Su tutti e sei gli sprint la media è di 29 punti con un intervallo da 21 a 35. Per la pianificazione, questo team dovrebbe aspettarsi circa 29–31 punti in uno sprint normale e considerare improbabile qualsiasi valore sopra 35 senza un cambiamento nel team o nel lavoro.

Gli story point non completati contano nella velocity?

No, gli story point non completati non contano nella velocity. Se una story è finita al 90% alla fine dello sprint, contribuisce con zero punti a quello sprint e la sua stima intera conta nello sprint in cui viene completata. Dividere i punti per «premiare» il lavoro parziale nasconde il vero problema, che di solito è una story troppo grande o uno sprint sovraccarico. Ristimare le story riportate è facoltativo; molti team mantengono la stima originale per evitare l’inflazione.

Bug e debito tecnico vanno contati nella velocity?

Bug e lavoro sul debito tecnico vanno contati nella velocity solo se il team li stima in punti prima dello sprint, come le story. Se la correzione di bug non pianificata viene esclusa, la velocity cala quando la qualità è scarsa, e questa è un’informazione utile. La regola importante è la coerenza: decidete una volta per tutte come il team tratta bug, spike e manutenzione, e mantenete stabile quella regola perché l’andamento resti confrontabile.

Che cosa serve per misurare la velocity con precisione?

Per misurare la velocity con precisione servono un team stabile, una durata fissa dello sprint, una Definition of Done rigorosa e una pratica di stima coerente. Quando una di queste quattro condizioni cambia, la velocity passata diventa un debole indicatore del lavoro futuro.

• Un team stabile. Aggiungere o togliere persone cambia la velocity, spesso per diversi sprint. I nuovi membri all’inizio rallentano il team mentre entrano nel ruolo.
• Durata dello sprint costante. Sprint di due settimane non si possono confrontare con sprint di tre settimane senza normalizzazione.
• Una Definition of Done solida. Se «finito» a volte significa «mergiato» e a volte «rilasciato», la velocity deriva per motivi che non hanno nulla a che fare con l’output.
• Una pratica di stima coerente. Le stesse story di riferimento e le stesse persone che stimano mantengono i punti confrontabili nel tempo.
• Uno strumento di tracciamento affidabile. Jira, Azure DevOps, Linear o uno strumento simile deve registrare correttamente i cambi di stato, altrimenti i dati sono incompleti.

Se il vostro team stima in ore o giorni invece che in punti, vale la stessa logica. La nostra guida alla stima dei progetti software confronta story point, stima a tre punti e altre tecniche che alimentano una pianificazione basata sulla velocity.

Come usano i team la velocity per pianificare sprint e rilasci?

I team usano la velocity come uno degli input per decidere quanto lavoro inserire nel prossimo sprint e per prevedere quando un backlog di dimensioni note sarà completato. La velocity orienta la decisione ma non la prende. Il team si impegna comunque in base a chi è davvero disponibile, a ciò che conta di più in quel momento e a ciò che potrebbe andare storto in quello specifico sprint.

Come fissare un obiettivo di sprint a partire dalla velocity

Nello Sprint Planning partite dalla velocity media e adattatela alle variazioni di capacità note. Se il team fa in media 30 punti e uno dei cinque ingegneri sarà assente per metà sprint, un obiettivo realistico è intorno ai 27 punti. Festività, reperibilità, onboarding e workshop programmati riducono la capacità e vanno sottratti prima che il team si impegni.

La guida a Scrum nello sviluppo software descrive come si combinano Sprint Planning, Sprint Goal e Sprint Backlog; la velocity serve solo a mantenere il perimetro scelto entro ciò che il team ha dimostrato di poter completare.

Prevedere un rilascio con un intervallo

Per prevedere un rilascio, dividete il backlog residuo per la velocity bassa e quella alta del team, così da ottenere un intervallo di date invece di una data singola. Con un backlog di rilascio di 240 punti e una velocity compresa tra 26 e 34 punti per sprint:

1. Caso ottimistico: 240 ÷ 34 ≈ 7 sprint.
2. Caso pessimistico: 240 ÷ 26 ≈ 9,2, quindi 10 sprint.
3. Conversione in calendario: con sprint di due settimane la previsione è di 14-20 settimane.

• Aggiungete un margine per la crescita del perimetro. I backlog di solito crescono durante la delivery man mano che il team impara; tracciate separatamente i cambi di perimetro perché restino visibili.
• Rifate la previsione a ogni sprint. Aggiornate l’intervallo con ogni nuovo dato invece di difendere la prima stima.
• Usate una previsione probabilistica per i rilasci più grandi. Una simulazione Monte Carlo, che riproduce migliaia di scenari possibili a partire dalla vostra velocity o dal throughput storici, dà risposte come «85% di probabilità entro la settimana 18», più oneste di una data singola.

Qual è la differenza tra velocity, capacità, throughput e produttività?

La velocity misura il lavoro completato per sprint, la capacità il tempo di lavoro disponibile, il throughput gli elementi completati per periodo e la produttività il rapporto tra output, valore e sforzo. Rispondono a domande diverse e si confondono facilmente, il che porta a decisioni sbagliate.

I team che lavorano in flusso continuo invece che a sprint raramente tracciano la velocity e si affidano a throughput, cycle time e limiti al work in progress; la guida a Kanban nello sviluppo software spiega questo modello. Per una visione più ampia della misurazione oltre lo sprint, leggete il nostro articolo sulla produttività nello sviluppo software.

Che cosa influenza la velocity nello sviluppo software?

La velocity nello sviluppo software dipende soprattutto da stabilità del team, dimensione del lavoro, interruzioni, debito tecnico e qualità della pipeline di delivery, non da quanto duramente lavorano le persone. Conoscere questi fattori aiuta a spiegare un calo prima che qualcuno chieda al team di «andare più veloce».

• Composizione e cambiamenti del team. Nuove assunzioni, uscite e ingegneri condivisi tra team fanno variare la velocity.
• Dimensione e chiarezza delle story. Story grandi e vaghe passano da uno sprint all’altro e rendono la velocity instabile.
• Lavoro non pianificato. Incidenti in produzione, richieste di supporto urgenti e richieste estemporanee degli stakeholder consumano capacità.
• Debito tecnico e salute del codice. Codice fragile, test mancanti e dipendenze complesse rallentano ogni modifica.
• Flusso di review e deployment. Lunghe code di code review, test manuali e pipeline CI lente ritardano il momento in cui il lavoro è «finito».
• Dipendenze esterne. Attendere un altro team, l’API di un fornitore o un’approvazione di sicurezza blocca lavoro altrimenti concluso.
• Work in progress. Iniziare molti elementi contemporaneamente disperde l’attenzione e ne fa completare meno.

La complessità dei task merita un’analisi a parte, perché lo stesso numero di punti può nascondere livelli di rischio molto diversi. La nostra guida alle metriche di complessità dei task nello sviluppo software tratta misure cognitive e a livello di codice che spiegano perché alcuni sprint si bloccano.

Velocity agile e developer velocity: qual è la differenza?

La velocity agile è un numero di pianificazione del team espresso in story point, mentre la «developer velocity» è un termine manageriale più ampio che indica quanto rapidamente un’organizzazione di ingegneria trasforma le idee in software funzionante. Le due condividono una parola ma rispondono a domande diverse.

Il termine developer velocity è stato reso popolare dalla ricerca McKinsey sul Developer Velocity Index del 2020, che collegava solide pratiche di ingegneria – strumenti, product management, cultura – alle performance aziendali. Secondo la ricerca McKinsey, le aziende nel quartile superiore dell’indice hanno aumentato i ricavi da quattro a cinque volte più velocemente di quelle nel quartile inferiore. La developer velocity, in questo senso, riguarda capacità e ambiente, non i punti di sprint.

Per le performance di delivery a livello di organizzazione, nel 2026 la maggior parte dei team usa le metriche DORA pubblicate dal programma DevOps Research and Assessment di Google: frequenza di deployment, lead time for changes, change failure rate e tempo di ripristino del servizio. Metriche di flusso come cycle time e work in progress completano il quadro. La velocity può affiancarle come supporto alla pianificazione del team, ma non deve sostituirle. Il nostro elenco di KPI per lo sviluppo software mostra come queste metriche si integrano.

Quali sono gli errori più comuni con la velocity?

L’errore più comune è trattare la velocity come un obiettivo di performance, cosa che gonfia rapidamente le stime e ne distrugge il valore per la pianificazione. La legge di Goodhart descrive bene l’effetto: quando una misura diventa un obiettivo, smette di essere una buona misura.

• Confrontare la velocity tra team. Ogni team ha la propria scala di punti; 40 punti in un team e 20 in un altro non dicono nulla su chi consegna di più.
• Fissare obiettivi di velocity. Chiedere «il 10% di punti in più nel prossimo trimestre» produce soprattutto stime più grandi, non più valore consegnato.
• Usare la velocity nelle valutazioni individuali. La velocity è una metrica di team; suddividerla per persona favorisce l’ottimizzazione locale e scoraggia pair programming e code review.
• Contare il lavoro parzialmente completato. Accreditare story non finite fa sembrare stabile la velocity quando la delivery non lo è.
• Ignorare la qualità. Una velocity in crescita accompagnata da più difetti sfuggiti o deployment falliti di solito significa che il team sta prendendo scorciatoie.
• Pianificare alla velocity massima. Impegnarsi sul miglior sprint di sempre non lascia spazio al lavoro imprevisto e fa sembrare un fallimento la maggior parte degli sprint.
• Ricalibrare gli story point in silenzio. Cambiare le story di riferimento senza azzerare lo storico della velocity rompe la confrontabilità.

Come migliorare la velocity senza manipolare gli story point?

La velocity si migliora in modo sostenibile eliminando gli attriti dal sistema di delivery – story troppo grandi, tempi di attesa, rilavorazioni – invece di spingere le persone a chiudere più punti. Un miglioramento reale si vede come velocity più alta o più stabile, con qualità costante e cycle time più breve.

1. Suddividete le story in parti più piccole. Gli elementi che stanno in due o tre giorni raramente vengono riportati, e la velocity diventa più prevedibile.
2. Limitate il work in progress. Finire prima di iniziare altro riduce i cambi di contesto e gli elementi lasciati a metà a fine sprint.
3. Riducete i tempi di code review e CI. Una review entro la giornata e una pipeline veloce e affidabile accorciano la strada verso «finito».
4. Investite nei test automatici. Una suite di test solida riduce i test di regressione manuali e le rilavorazioni dovute ai difetti sfuggiti.
5. Ripagate il debito tecnico in modo deliberato. Riservate una quota fissa di ogni sprint al debito nelle aree che rallentano di più il team.
6. Proteggete il team dal lavoro imprevisto. Fate passare supporto e richieste urgenti da una sola persona a rotazione invece di interrompere tutti.
7. Conducete le retrospettive su dati reali. Osservate riporti, tempo bloccato e cycle time, scegliete un miglioramento per sprint e verificate se ha funzionato.

Come cambiano la velocity gli strumenti di coding con IA nel 2026?

Gli assistenti di coding con IA possono aumentare la quantità di codice prodotto, ma nel 2026 rendono la velocity più difficile da interpretare, perché programmare più in fretta non significa automaticamente consegnare più in fretta software funzionante. Quando adottano strumenti di IA, i team dovrebbero monitorare metriche di qualità e stabilità accanto alla velocity.

Il report DORA 2025 sullo sviluppo software assistito dall’IA ha rilevato che circa il 90% dei professionisti tecnologici intervistati usa l’IA al lavoro e che l’adozione dell’IA ha ora una relazione positiva con il throughput di delivery. La stessa ricerca ha rilevato che l’adozione dell’IA continua a essere correlata a una maggiore instabilità della delivery, cioè più modifiche fallite e più rilavorazioni. DORA descrive l’IA come un amplificatore: rafforza i buoni sistemi di ingegneria e mette in luce quelli deboli.

• Ricalibrate le stime. Se i task di routine diventano più rapidi con l’IA, le story di riferimento potrebbero richiedere una nuova stima; in quel caso azzerate la baseline della velocity.
• Monitorate il carico di review. Più codice generato spesso sposta il collo di bottiglia su code review e test, e questo limita la velocity reale.
• Tracciate il change failure rate. Un aumento della velocity con un change failure rate in crescita non è un miglioramento.

Che cosa dice la velocity su un team di sviluppo in outsourcing?

La velocity vi dice se un team in outsourcing è prevedibile, non se è produttivo o se vale quanto costa. Una velocity stabile con intervalli di rilascio onesti è un buon segnale; una velocity che non fa che salire indica di solito inflazione.

Quando lavorate con un team esterno o con un team di sviluppo dedicato, fate quattro domande semplici: come stimate, che cosa include la vostra Definition of Done, che fine fanno i riporti e come prevedete un rilascio? Poi chiedete di vedere la velocity accanto a cycle time, difetti sfuggiti e frequenza di deployment. Un partner che comunica solo story point, o che promette una velocity fissa prima di conoscere la vostra codebase, vende un numero invece di un processo di delivery.

Domande frequenti