What Is Velocity in Agile?

Velocity based estimation is an agile planning technique that uses a team's historical rate of completed work, measured in story points or similar units per sprint, to forecast how much work the team can deliver in future iterations. It replaces guesswork with a data-driven baseline derived from actual past performance. Teams use velocity as a planning input to set realistic sprint commitments and project timelines.

Sprint planning without a grounded capacity measure leads to chronic overcommitment. When teams guess at how much work they can absorb, they tend to plan optimistically, which produces missed deadlines and rushed delivery. According to the 16th State of Agile Report, only 37% of agile teams report that their sprint commitments are consistently met, a gap that velocity based estimation is designed to close.

Velocity provides a self-correcting feedback loop. If a team's average velocity is 40 story points per two-week sprint, planning 60 points of work is a clear overcommitment that can be caught before the sprint begins. Over time, velocity trends also reveal whether a team is accelerating, plateauing, or slowing down, each of which signals different underlying conditions.

The technique also improves communication with stakeholders. Instead of promising "we will try to finish these features by March," a team can say "based on our velocity, we can complete an estimated 120 story points in the next three sprints, which covers these specific items." That specificity builds credibility and makes tradeoff conversations more productive. Understanding why sprint planning breaks down often starts with examining whether teams are using velocity data effectively.

Calculating velocity is straightforward. At the end of each sprint, the team sums the story points of all completed items. After several sprints, typically six or more, the average and range of these totals form the velocity baseline. Most teams use a rolling average of the last three to six sprints to account for natural variation.

During planning, the team uses this velocity figure to set a target for the upcoming sprint. If the rolling average is 42 points, the team pulls items from the backlog totaling roughly 42 points. Importantly, only fully completed items count toward velocity. Partially finished work is excluded, which keeps the metric honest.

The technique works best when combined with consistent estimation practices. If the team's definition of a "3-point story" shifts over time, velocity loses its predictive power. Regular calibration through sprint estimation exercises, where the team compares estimates against actuals, helps maintain consistency.

Most agile project management tools include built-in velocity tracking. Jira, Azure DevOps, Linear, and Shortcut all generate velocity charts that show completed points per sprint over time. Dedicated analytics tools like LinearB and Jellyfish provide deeper breakdowns of velocity by team, project, or work type.

Glue enhances velocity based estimation by connecting delivery speed to codebase context. When a team's velocity drops, Glue can help identify whether the cause is growing code complexity, shifting dependencies, or increased review cycles. That diagnostic capability turns velocity from a lagging indicator into a starting point for targeted improvement.

What is a good velocity for a software team?

There is no universal "good" velocity because the metric is team-specific. A team estimating in story points on a Fibonacci scale will have different numbers than a team using t-shirt sizes converted to numeric values. The useful comparison is a team's current velocity against its own historical trend, not against other teams.

Can velocity based estimation work without story points?

Yes. Some teams track velocity using completed ticket counts, ideal engineering days, or other units. The key requirement is a consistent unit of measurement applied over multiple sprints so that the historical average is meaningful.

Why does velocity fluctuate between sprints?

Velocity naturally varies due to factors like team member absences, unplanned work, varying task complexity, and interruptions. A range of plus or minus 15 to 20 percent from the average is typical. Persistent downward trends, rather than normal fluctuation, are what signal a need for investigation.