Velocity-Based Estimation: A Practical Guide

By Priya Shankar, Head of Product at Glue

If you have ever tried to answer "when will this be done?" in a sprint planning meeting, you have already encountered velocity-based estimation. It is one of the most widely used methods in agile software development, and for good reason. When applied correctly, velocity-based estimation turns your team's historical throughput into a planning tool that is grounded in reality rather than wishful thinking.

But there is a catch. Most teams measure velocity wrong, interpret it wrong, and use it for things it was never designed to do.

This guide breaks down what velocity-based estimation actually is, how to measure it accurately, where teams go wrong, and which tools can help.

Velocity-based estimation is a planning technique where teams use their past rate of completed work to forecast how much they can accomplish in future sprints. The core idea is simple: if your team completed an average of 40 story points per sprint over the last six sprints, you can reasonably plan for about 40 points in the next sprint.

The term "velocity" comes from agile and Scrum methodologies. It represents the amount of work a team finishes in a single iteration, measured in whatever unit the team uses: story points, ideal days, or task counts.

The appeal of velocity is that it is empirical. Rather than asking people to predict the future, you look at what actually happened. A team that has consistently delivered 35-45 points per sprint has a more reliable planning baseline than a team that "feels like" they can do 60 next time.

However, velocity is not a productivity metric. It is a capacity planning tool. This distinction matters, and confusing the two is the source of most velocity-related problems.

How Velocity Fits Into Sprint Planning

In a typical sprint planning process, velocity serves as a guardrail. The team reviews their average velocity, pulls items from the backlog until they reach that capacity, and commits to the sprint. The goal is to avoid both overcommitment (too much work) and undercommitment (too little ambition).

Research from the Standish Group indicates that 66% of software projects experience cost overruns, often because teams commit to more work than they can realistically complete. Velocity-based estimation, when done properly, directly addresses this by anchoring plans in historical data.

Accurate velocity measurement requires consistency and honesty. Here are the practices that separate useful velocity data from noise.

Use a Stable Estimation Unit

Pick one estimation method and stick with it. Whether your team uses story points, ideal hours, or simple task counts, switching between units invalidates your historical data. Velocity comparisons only work when the unit of measurement stays constant.

Track Completed Work Only

Velocity counts work that is done, not work that is in progress. A ticket that is 90% complete at the end of a sprint contributes zero to that sprint's velocity. This feels harsh, but it keeps the metric honest. Partial credit creates inflated baselines that lead to overcommitment.

Average Over Multiple Sprints

A single sprint's velocity is noisy. Team members take vacation, unexpected incidents pull focus, and some sprints just have harder work. Use a rolling average of your last 4-6 sprints to smooth out variability.

Here is a simple approach:

This team should plan for roughly 40 points per sprint. The range of 32-45 also gives useful information: it suggests that committing to more than 45 is risky, while planning for less than 32 is overly conservative.

Account for Team Changes

Velocity is team-specific. When someone joins or leaves, your historical velocity becomes less reliable. Give the new team composition 2-3 sprints to establish a new baseline before relying on it for planning.

Velocity is a straightforward concept, but teams find creative ways to misuse it. These are the patterns I have seen cause the most damage.

Anti-Pattern 1: Using Velocity as a Performance Metric

The moment velocity becomes a KPI that managers review, teams start gaming it. Estimates inflate. Easy tickets get prioritized over important ones. The number goes up, but actual output does not.

Velocity measures capacity, not productivity. Comparing velocity between teams is meaningless because different teams estimate differently. A team with a velocity of 20 might be outperforming a team with a velocity of 80 if their estimation calibrations differ.

Anti-Pattern 2: The Velocity Ratchet

Some organizations expect velocity to increase every quarter. This creates unsustainable pressure. Teams respond by inflating estimates so that the same work produces higher point totals. Over time, a "5-point story" today is what a "3-point story" was six months ago. The chart trends upward while actual throughput stays flat.

Anti-Pattern 3: Ignoring Context Behind the Numbers

A sprint where velocity dropped from 40 to 25 is not necessarily a problem. Maybe the team tackled a high-risk refactoring. Maybe they invested in test automation that will pay dividends for months. Velocity without context is a dangerous number.

This is where codebase visibility tools become essential. If you can see that a low-velocity sprint involved changes to heavily coupled, high-churn files, you understand why it was slower. Without that context, the number just looks like underperformance.

Anti-Pattern 4: Planning Without Codebase Context

Even accurate velocity data cannot tell you whether a specific set of tickets will fit in a sprint. Ten tickets totaling 40 points might be straightforward if they touch isolated modules. Or they might be impossible if they all depend on the same fragile service that only one engineer understands.

Glue's codebase analysis adds the missing dimension. By mapping file-level dependencies, ownership concentration, and complexity hotspots, Glue helps teams understand whether their planned work is realistic, regardless of what the point totals suggest.

Effective velocity tracking requires more than a spreadsheet. Here is what a solid tooling stack looks like.

Project Management Layer

Your issue tracker (Jira, Linear, Shortcut) handles the basics: tracking what was committed, what was completed, and calculating sprint velocity over time. Most tools do this reasonably well out of the box.

The Missing Layer: Codebase Intelligence

Standard velocity tools track what was completed. They do not tell you what it actually involved at the code level. This gap is why teams with "good" velocity data still miss their commitments.

Glue fills this gap by connecting your planned work to your actual codebase. Before a sprint starts, you can see which files each ticket will likely touch, who owns those files, and whether there are coupling risks that could slow things down. After a sprint ends, you can understand why certain tickets took longer than expected by looking at the code-level complexity involved.

Building a Complete Picture

The most effective estimation workflows combine velocity data with codebase context:

1. Review your rolling velocity average to set an overall capacity target.
2. Use Glue's impact analysis to validate that planned tickets fit within that capacity, accounting for code-level complexity.
3. Track cycle time per ticket to identify which types of work consistently take longer than estimated.
4. Review post-sprint to calibrate future estimates against what actually happened in the codebase.

This combination gives you both the macro view (how much can we do?) and the micro view (what does this specific work actually involve?). Neither tool alone is sufficient.

Making Velocity Work for Your Team

Velocity-based estimation is not perfect. No estimation method is. But it has one significant advantage over alternatives: it is grounded in empirical data about what your team has actually accomplished.

The key is treating velocity as a planning input, not a performance measure. Combine it with codebase visibility tools that fill the context gap. And resist the organizational pressure to turn it into a target.

Your team's velocity is not a grade. It is a compass.

---

Want to see what your planned work actually involves at the code level? Try Glue free and bring codebase intelligence into your sprint planning.

---

What is velocity-based estimation?

Velocity-based estimation is an agile planning technique that uses a team's historical rate of completed work to forecast future sprint capacity. Instead of guessing how much work the team can handle, you look at how much they have actually finished in recent sprints and use that average as a planning baseline. It works best when combined with consistent estimation practices and stable team composition.

How do you calculate team velocity?

To calculate team velocity, sum the story points (or whatever estimation unit your team uses) for all tickets completed during a sprint. Then take a rolling average across the last 4-6 sprints to account for natural variability. Only count fully completed work, not tickets that are partially done. This average becomes your planning baseline for future sprints.

Is velocity a good estimation metric?

Velocity is a useful capacity planning tool but a poor performance metric. It works well for answering "how much can we commit to next sprint?" based on historical data. It fails when used to compare teams, set increasing targets, or measure individual productivity. For the best results, pair velocity with codebase visibility tools like Glue that reveal the code-level complexity behind your planned work.