Most engineering leaders can tell you their squad shipped 42 story points last sprint. Far fewer can tell you whether that number is improving, declining, or what's actually driving it. Engineering velocity measures how much valuable work a software team delivers over a given period, and without a clear view of it, your delivery commitments are little more than educated guesses. This page covers the definition, how to measure it, what good looks like, how to improve it, and how DevStats surfaces the data you need to act.
Key takeaways
- Engineering velocity measures the rate at which a squad delivers completed work over a defined time period. It matters because it is the foundation of reliable delivery forecasting: without it, sprint commitments are guesses, roadmaps are fiction, and stakeholder trust erodes every time a release slips.
- Velocity is typically calculated as total story points (or issues) completed per sprint. A high-performing squad of 6 to 8 engineers on a two-week sprint cycle often sustains 60 to 90 story points, but benchmarks vary significantly by team size, ticket sizing conventions, and sprint length, so internal trends matter more than raw numbers.
- The most common mistake teams make is treating velocity as a productivity score. Velocity measures the delivery process, not the worth of individual players. Comparing velocity across squads with different sizing conventions or codebases produces misleading conclusions and erodes the psychological safety that makes squads perform well.
- DevStats tracks engineering velocity automatically by connecting to your Git provider and issue tracker, with benchmarks against 1,000+ engineering teams. Start a free trial to see your squad's numbers in under two minutes.
Engineering velocity definition
Engineering velocity is the amount of work a software development team completes in a fixed time period, most commonly a sprint. It gives engineering leaders a repeatable signal for how much a squad can reliably deliver, which makes it the core input to release planning and roadmap forecasting.
Technically, velocity is calculated as: Velocity = Total story points (or issues) completed / Number of sprints measured. Most teams track a rolling average across three to six sprints to smooth out outliers. When teams use issue counts rather than story points, pairing velocity with throughput data gives a more complete picture of delivery rate. Teams that ship consistently at a predictable velocity earn stakeholder confidence that directly translates to better roadmap alignment and reduced scope-creep pressure.
Why engineering velocity matters for engineering teams
When squads don't track velocity, delivery problems stay invisible until they become emergencies. A team might feel busy across every sprint while consistently under-delivering against commitments, with no clear signal about where work is stalling. Without velocity data, engineering leaders can't distinguish between a squad that's blocked by external dependencies and one that's simply taking on more than it can finish. The result is missed sprints, eroding trust with product and business stakeholders, and a planning process that never improves.
Velocity connects directly to the KPIs engineering leaders are held to: on-time delivery, predictable release cadence, and the ability to give the business a credible answer when asked "when will this ship?" It also feeds into planning accuracy, which measures how closely sprint commitments match sprint outcomes. Teams with high planning accuracy tend to have stable, well-understood velocity. Within the SPACE framework, velocity sits at the intersection of Activity and Efficiency, capturing output without reducing it to lines of code or hours worked.
Measuring velocity is the diagnostic step. What an engineering leader does with that data, whether that's adjusting sprint scope, removing blockers, or restructuring how work is sized, is where the real improvement happens.
How to measure engineering velocity
The standard calculation takes total story points completed across a sprint and averages that figure over three to six sprints to produce a reliable baseline. "Completed" means accepted by the product owner and meeting the team's definition of done, not just moved to a done column. The data sources you need are your issue tracker (Jira, Linear, GitHub Issues) and your Git provider for PR merge confirmation. For teams that don't use story points, issue count per sprint is a workable proxy, especially when combined with issue cycle time to account for ticket complexity.
No universally published benchmark for story-point velocity exists in the way DORA benchmarks exist for deployment frequency, because velocity is heavily dependent on how a team sizes tickets. What matters most is your squad's own trend over time. The table below describes qualitative performance levels based on patterns seen across engineering teams, using trend stability as the primary signal. You can compare your squad's patterns against peer teams using DevStats benchmarks.
| Performance level | Engineering velocity signal | What it signals |
|---|---|---|
| Elite | Stable or improving trend, low sprint-to-sprint variance (under 10%) | Predictable delivery, well-sized tickets, minimal unplanned work |
| High | Mostly stable trend, moderate variance (10–20%) | Reliable squad with occasional disruption from scope changes or incidents |
| Medium | Flat or inconsistent trend, variance above 20% | Planning or sizing issues, likely blocked work or frequent scope changes |
| Low | Declining trend or high variance across multiple sprints | Systemic bottleneck: dependency drag, tech debt, or team capacity mismatch |
Note: Benchmarks vary by team size, codebase maturity, and sprint length. Use these levels as directional signals, not absolute targets.
Engineering velocity in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed that her platform squad's velocity had dropped from a rolling average of 72 points per sprint to 48 over six weeks. The squad wasn't reporting any major blockers in standups. When she pulled sprint data and cross-referenced it with PR cycle time, she found that review turnaround had ballooned from under 4 hours to over 2 days. Two senior players were bottlenecking reviews for the rest of the squad, not out of negligence but because they'd taken on architecture work that wasn't reflected in sprint planning.
She made two changes: she redistributed review assignments to spread the load across three players, and she added architecture work as explicit sprint items so it would count against capacity in planning. Within three sprints, velocity recovered to 68 points and sprint-to-sprint variance dropped. The data told her where to look. The intervention was hers to design and execute.
How to improve engineering velocity
- Audit your sprint scope discipline. Pull the last six sprints and count how many tickets were added after sprint start. Unplanned work is the single biggest velocity killer. Set a rule: no new tickets enter a sprint without removing equivalent scope. Track this using your sprint data to see whether scope stability correlates with velocity improvement.
- Right-size your tickets. If your squad regularly carries tickets across sprint boundaries, your stories are too large. Break any ticket estimated above 5 points into sub-tasks. Smaller, well-defined tickets reduce the chance of partially completed work inflating your in-progress count while deflating your velocity.
- Cut review bottlenecks. Slow code review is a leading indicator of velocity decline. If PR cycle time is rising, velocity will follow. Set a team norm for first-review response time (under 4 hours is a reasonable target for most squads) and review your code review data weekly to catch drift early.
- Make capacity visible before sprint planning. Velocity forecasts break down when planned capacity doesn't match actual availability. Account for PTO, on-call rotations, and cross-team commitments before locking sprint scope. DevStats surfaces allocation data that shows how engineering time is actually distributed across work types, which makes capacity planning more accurate.
- Separate velocity from performance evaluation. Squads that know velocity is used to judge individual players will game it. Keep velocity as a process metric, review it at the squad level, and use it only to improve planning, not to rank people.
Engineering velocity vs. throughput
Engineering velocity and throughput are related but measure different things: velocity tracks the weighted value of work completed (story points), while throughput counts the raw number of items delivered regardless of size.
| Engineering velocity | Throughput | |
|---|---|---|
| Measures | Story points or weighted work completed per sprint | Number of items (PRs, issues, tickets) completed per period |
| Starts when | Sprint begins | Item enters the workflow |
| Ends when | Sprint closes and items are accepted | Item is merged or marked done |
| Best for | Sprint planning and release forecasting | Continuous flow teams and delivery rate trending |
Use velocity when your squad works in sprints with story point estimation. Use throughput when your team operates in a continuous flow model or when you want a sizing-agnostic view of delivery rate.