Velocity Software Development Guide: How to Measure Agile Velocity in 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Velocity (software development) is the simplest forecasting tool in agile: add up the work a team finished in a sprint, average it over several sprints, and you know roughly how much the team can take on next time. The idea comes from Extreme Programming and is now standard in Scrum and other iterative frameworks, yet it is also one of the most misused numbers in engineering management.

Used well, velocity turns a planning meeting into a short conversation grounded in data. Trouble starts when someone turns it into a target: estimates creep up, and within a quarter or two the number means very little. Teams that buy outcome-driven product engineering services usually see velocity next to delivery and product metrics, not alone, because a stable velocity says nothing about whether the shipped work moved a business KPI.

Below you will find the formula with a six-sprint worked example, a release forecast you can copy, a comparison of velocity with capacity, throughput and DORA metrics, and the mistakes that turn velocity into a vanity number, including the new ones that AI coding tools bring in 2026.

What is velocity in software development?

Velocity in software development is the amount of work an agile team completes during one iteration, measured in the same relative units the team uses to estimate, most often story points (relative estimates of effort, complexity and uncertainty rather than hours). Only work that meets the team’s Definition of Done, the shared checklist that says when an item is truly finished, counts, and the number is used to forecast how much the same team can complete in future iterations.

Velocity is an empirical measure: it records what happened rather than predicting what should happen. The value of velocity lies in the trend over several sprints, not in any single sprint. A team that completed 30, 34 and 32 points in its last three two-week sprints has a velocity of about 32 points per sprint, and that figure is meaningful only for that team, with its estimation scale, its codebase and its definition of done.

The concept appeared in Extreme Programming in the late 1990s, where teams used the amount of work finished in the last iteration (“yesterday’s weather”) to plan the next one. Mike Cohn’s book Agile Estimating and Planning later popularised velocity alongside story points. The official Scrum Guide does not require velocity at all; it only says that past performance and the team’s capacity inform how much work is selected in Sprint Planning.

Sprint velocity vs team velocity

Sprint velocity is the number of points completed in one specific sprint, while team velocity is the average across several recent sprints. Sprint velocity is a data point; team velocity is the planning figure. Planning on a single sprint is risky because one sprint can be distorted by a holiday, a production incident or an unusually large story finishing on the last day.

Which units can you use to measure velocity?

Story points are the most common unit of velocity, but any consistent unit of completed work can be used. The choice matters less than keeping it stable over time.

• Story points: relative estimates of effort, complexity and uncertainty, often on a Fibonacci-like scale (1, 2, 3, 5, 8, 13).
• Ideal days or hours: estimates of uninterrupted effort, easier to explain to stakeholders but more prone to being read as time commitments.
• Number of items: completed stories or tickets per sprint, which works well when work is sliced into items of similar size.
• T-shirt sizes converted to numbers: S, M and L mapped to fixed values, a compromise for teams new to estimation.

Counting items rather than points removes the estimation ritual and behaves like throughput. It only works if the team consistently splits work into small, comparable pieces.

How do you calculate agile software development velocity?

To calculate agile software development velocity, add the story points of every item that met the Definition of Done in a sprint, then average that total across the last three to five sprints of equal length. The formula is: velocity = sum of completed story points in the sampled sprints ÷ number of sprints sampled.

1. Fix the sprint length. Use iterations of the same duration, for example two weeks, otherwise sprints are not comparable.
2. Count only finished work. An item counts when it meets the Definition of Done: coded, reviewed, tested and accepted. Partially finished items count as zero.
3. Sum the points per sprint. Add up the estimates of all completed items; that total is the sprint velocity.
4. Average several sprints. Take a rolling average of the last three to five sprints to smooth out noise.
5. Report a range, not one number. Note the lowest and highest recent values alongside the average, because the spread is what makes forecasts honest.

The table below shows a worked example for a team of five engineers working in two-week sprints.

A rolling average of the last three sprints (35, 21 and 33) gives a velocity of about 30 points. Over all six sprints the average is 29 points with a range of 21 to 35. For planning, this team should expect roughly 29–31 points in a normal sprint and treat anything above 35 as unlikely without a change in the team or the work.

Do unfinished story points count toward velocity?

No, unfinished story points do not count toward velocity. If a story is 90% done at the end of the sprint, it contributes zero points to that sprint and its full estimate counts in the sprint where it is finished. Splitting the points to “give credit” for partial work hides the real problem, which is usually that the story was too large or the sprint was overloaded. Re-estimating carried-over stories is optional; many teams keep the original estimate to avoid inflation.

Should bugs and technical debt count in velocity?

Bugs and technical debt work should count in velocity only if the team estimates them in points before the sprint, in the same way as stories. If unplanned bug fixing is excluded, velocity falls when quality is poor, which is useful information. The important rule is consistency: decide once how the team treats bugs, spikes and maintenance, and keep that rule stable so the trend stays comparable.

What do you need to measure velocity accurately?

You need a stable team, fixed sprint length, a strict Definition of Done and consistent estimation to measure velocity accurately. When any of these four conditions changes, past velocity becomes a weak predictor of future work.

• A stable team. Adding or removing people changes velocity, often for several sprints. New members first slow the team down while they ramp up.
• Consistent sprint length. Two-week sprints cannot be compared with three-week sprints without normalisation.
• A strong Definition of Done. If “done” sometimes means “merged” and sometimes “released”, velocity drifts for reasons that have nothing to do with output.
• Consistent estimation practice. The same reference stories and the same people estimating keep points comparable over time.
• A reliable tracking tool. Jira, Azure DevOps, Linear or a similar tool must record status changes accurately, otherwise the data is incomplete.

If your team estimates in hours or days rather than points, the same logic applies. Our software project estimation guide compares story points, three-point estimates and other techniques that feed into velocity-based planning.

How do teams use velocity in sprint and release planning?

Teams use velocity as one input to decide how much work to pull into the next sprint and to forecast when a backlog of known size will be finished. It informs the decision but doesn't make it. The team still commits based on who is actually available, what matters most right now and what could go wrong in that particular sprint.

How to set a sprint target from velocity

In sprint planning, start from the average velocity and adjust it for known changes in capacity. If the team averages 30 points and one of five engineers will be away for half the sprint, a realistic target is around 27 points. Holidays, on-call duty, onboarding and planned workshops all reduce capacity and should be subtracted before the team commits.

The Scrum software development guide describes how Sprint Planning, the Sprint Goal and the Sprint Backlog fit together; velocity simply keeps the selected scope within what the team has proven it can finish.

Forecasting a release with a range

To forecast a release, divide the remaining backlog by the team’s low and high velocity to get a date range rather than a single date. For a release backlog of 240 points and a velocity range of 26 to 34 points per sprint:

1. Optimistic case: 240 ÷ 34 ≈ 7 sprints.
2. Pessimistic case: 240 ÷ 26 ≈ 9.2, so 10 sprints.
3. Convert to calendar time: with two-week sprints, the forecast is 14 to 20 weeks.

• Add a scope-growth buffer. Backlogs typically grow during delivery as teams learn more; track scope change separately so it is visible.
• Re-forecast every sprint. Update the range with each new data point rather than defending the first estimate.
• Use probabilistic forecasting for larger releases. Monte Carlo simulation, which replays thousands of possible futures from your historical velocity or throughput, gives answers such as “85% likely by week 18”, which is more honest than one date.

What is the difference between velocity, capacity, throughput and productivity?

Velocity measures completed work per sprint, capacity measures available working time, throughput counts finished items per period, and productivity relates output to value and effort. They answer different questions and are easy to confuse, which leads to bad decisions.

Teams that run a continuous-flow process instead of sprints rarely track velocity and rely on throughput, cycle time and work-in-progress limits; the Kanban software development guide explains that model. For a broader view of measurement beyond the sprint, see our article on productivity in software development.

What affects software development velocity?

Software development velocity is affected mostly by team stability, work size, interruptions, technical debt and the quality of the delivery pipeline, not by how hard people work. Knowing them helps you explain a dip before anyone starts asking the team to “go faster”.

• Team composition and changes. New hires, departures and shared engineers between teams all move velocity.
• Size and clarity of stories. Large, vague stories carry over between sprints and make velocity volatile.
• Unplanned work. Production incidents, urgent support requests and ad-hoc requests from stakeholders consume capacity.
• Technical debt and code health. Fragile code, missing tests and complex dependencies slow every change.
• Review and deployment workflow. Long code review queues, manual testing and slow CI pipelines delay the moment work becomes “done”.
• External dependencies. Waiting for another team, a vendor API or a security approval stalls otherwise finished work.
• Work in progress. Starting many items at once spreads attention and finishes fewer of them.

Task complexity deserves a separate look, because the same number of points can hide very different levels of risk. Our guide to software development task complexity metrics covers cognitive and code-level measures that explain why some sprints stall.

Agile velocity vs developer velocity: what is the difference?

Agile velocity is a team-level planning number in story points, while “developer velocity” is a broader management term for how quickly an engineering organisation turns ideas into working software. The two share a word but answer different questions.

The term developer velocity was popularised by McKinsey’s 2020 Developer Velocity Index research, which linked strong engineering practices such as tools, product management and culture to business performance. The McKinsey research found that companies in the top quartile of the index grew revenue four to five times faster than those in the bottom quartile. Developer velocity in that sense is about capabilities and environment, not sprint points.

For organisation-wide delivery performance, most teams in 2026 use the DORA metrics published by Google’s DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate and time to restore service. Flow metrics such as cycle time and work in progress complete the picture. Velocity can sit next to them as a team planning aid, but it should not replace them. Our list of software development KPIs shows how these metrics fit together.

What are the most common velocity mistakes?

The most common velocity mistake is treating it as a performance target, which quickly inflates estimates and destroys its value for planning. Goodhart’s law describes the effect well: when a measure becomes a target, it ceases to be a good measure.

• Comparing velocity between teams. Each team has its own point scale, so 40 points in one team and 20 in another say nothing about who delivers more.
• Setting velocity goals. Asking for “10% more points next quarter” mostly produces bigger estimates, not more delivered value.
• Using velocity in individual performance reviews. Velocity is a team metric; splitting it per person encourages local optimisation and discourages pairing and code review.
• Counting partially done work. Giving credit for unfinished stories makes velocity look stable while delivery is not.
• Ignoring quality. A rising velocity combined with more escaped defects or failed deployments usually means the team is cutting corners.
• Planning at maximum velocity. Committing to the best sprint ever leaves no room for unplanned work and makes most sprints look like failures.
• Re-baselining story points silently. Changing reference stories without resetting the velocity history breaks comparability.

How can you improve velocity without gaming story points?

You improve velocity sustainably by removing friction from the delivery system, such as large stories, waiting time and rework, rather than by pushing people to finish more points. Real improvement shows up as a higher or more stable velocity together with steady quality and shorter cycle time.

1. Slice stories smaller. Items that fit in two or three days rarely carry over, which makes velocity more predictable.
2. Limit work in progress. Finishing before starting new work reduces context switching and half-done items at sprint end.
3. Shorten code review and CI time. Review within a working day and a fast, reliable pipeline shorten the path to “done”.
4. Invest in automated tests. A solid test suite reduces manual regression and the rework that follows escaped defects.
5. Pay down technical debt deliberately. Reserve a fixed share of each sprint for debt in the areas that slow the team most.
6. Protect the team from unplanned work. Route support and urgent requests through one rotating person instead of interrupting everyone.
7. Use retrospectives on real data. Look at carry-over, blocked time and cycle time, choose one improvement per sprint and check whether it worked.

How do AI coding tools change velocity in 2026?

AI coding assistants can raise the amount of code a team produces, but in 2026 they make velocity harder to interpret, because faster coding does not automatically mean faster delivery of working software. Teams should watch quality and stability metrics next to velocity when they adopt AI tools.

The 2025 DORA report on AI-assisted software development found that about 90% of surveyed technology professionals use AI at work and that AI adoption now has a positive relationship with delivery throughput. The same research found that AI adoption continues to correlate with higher delivery instability, meaning more change failures and rework. DORA describes AI as an amplifier: it strengthens good engineering systems and exposes weak ones.

• Re-calibrate estimates. If routine tasks become faster with AI, reference stories may need re-estimating; reset the velocity baseline when you do.
• Watch review load. More generated code often moves the bottleneck to code review and testing, which caps real velocity.
• Track change failure rate. A velocity increase with a rising change failure rate is not an improvement.

What can velocity tell you about an outsourced development team?

Velocity tells you whether an outsourced team is predictable, not whether it is productive or good value. A stable velocity with honest release ranges is a healthy sign; a velocity that only ever goes up is usually a sign of inflation.

When you work with an external or dedicated development team, ask four plain questions: how do you estimate, what does your Definition of Done include, what happens to carry-over, and how do you forecast a release? Then ask to see velocity next to cycle time, escaped defects and deployment frequency. A partner that reports only story points, or that promises a fixed velocity before it knows your codebase, is selling a number rather than a delivery process.

Frequently asked questions