Agile Sprint Velocity Calculator

What Is Sprint Velocity?

In agile and Scrum, velocity is the average amount of work a team finishes in a sprint, usually measured in story points per sprint. It is a team-level planning metric, not a measure of individual productivity or performance.

The calculator on this page helps you turn your recent delivery history into a single, easy-to-use number. By entering the total story points completed and the number of past sprints, you receive your team’s average velocity. You can then use that value to:

• Estimate how many story points your team can reasonably commit to in the next sprint.
• Roughly forecast how many sprints are needed to finish the remaining backlog.
• Spot trends in delivery over time (e.g., improving, stable, or declining capacity).

How This Velocity Calculator Works

The calculator uses a simple average based on your historical data. You provide:

• Total story points completed across several past sprints (only work that is fully done).
• Number of sprints included in that total.

It then computes your team’s average velocity as story points per sprint. This is the key planning unit in Scrum-based forecasting.

For example, if your team completed 180 points over the last 5 sprints, the calculator divides 180 by 5 and reports a velocity of 36 points per sprint.

Velocity Formula

The standard formula for average sprint velocity is:

Velocity = Total completed story points ÷ Number of sprints

Using mathematical notation:

Where:

• V is the average velocity (story points per sprint).
• P is the total number of completed story points across the selected sprints.
• S is the number of sprints included in that total.

In plain language, you add up all the completed story points for the sprints you are considering, then divide by how many sprints there were. The result is the average points your team finishes in one sprint.

Interpreting the Result

The calculator returns a single number, for example 34. You should read this as:

• 34 story points per sprint on average.

Here are some practical ways to use that number:

• Sprint planning: Use your average velocity as a starting point for how many points to pull into the next sprint. If your velocity is 34, you might tentatively plan 30–34 points, then adjust for holidays, absences, or especially risky work.
• Release forecasting: If your product backlog or a specific release scope has, say, 200 points remaining, divide 200 by your velocity to estimate how many sprints you will need.
• Trend analysis: Track velocity over time to see whether it is relatively stable. Big swings often indicate process issues, estimation changes, or major context changes (e.g., new team members).

Velocity is best used as a range rather than a single exact figure. Many teams look at a band such as “we usually deliver between 30 and 36 points per sprint” and plan conservatively within that band.

Worked Example

Suppose your Scrum team has just finished its fifth sprint. Over those five sprints, you completed the following story points:

• Sprint 1: 28 points
• Sprint 2: 32 points
• Sprint 3: 30 points
• Sprint 4: 35 points
• Sprint 5: 25 points

First, add them together:

28 + 32 + 30 + 35 + 25 = 150 points total.

Next, count the number of sprints: there are 5.

Apply the formula:

V = 150 ÷ 5 = 30 points per sprint

In the calculator, you would enter:

• Total story points completed: 150
• Number of sprints: 5

The reported velocity is 30. You could then use this to answer questions such as:

• “How many points can we plan next sprint?” — Start around 30 points, then adjust based on known time off or risky work.
• “Roughly how many sprints until we finish a 210-point backlog?” — 210 ÷ 30 = 7 sprints. If sprints are two weeks long, that is about 14 weeks, assuming scope does not grow.

Using Velocity to Forecast Backlog Completion

Once you know your velocity, you can make simple, high-level forecasts. A common use case is estimating how many sprints remain for a given backlog or release scope.

Use this rule of thumb:

Number of sprints ≈ Remaining story points ÷ Velocity

For example, if you have 260 story points remaining and your average velocity is 32 points per sprint:

260 ÷ 32 ≈ 8.1 → approximately 8–9 sprints.

Remember that this is an approximation. Backlogs evolve, requirements change, and teams improve their collaboration practices. Regularly recalculate velocity using the latest finished sprints and adjust your forecast accordingly.

Comparison: Velocity vs. Other Planning Approaches

Velocity is one of several ways teams plan and forecast. The table below compares it with a few related concepts.

This calculator assumes you already use story points in Scrum or a similar framework. If your team does not estimate in points, alternative approaches like throughput or cycle time may be more appropriate.

Assumptions and Limitations

Velocity is powerful but easy to misuse. Keep these assumptions and caveats in mind when using the result from this calculator:

• Consistent sprint length: The formula assumes that all sprints are roughly the same duration (for example, every sprint is two weeks). Mixing one-week and three-week sprints in the same calculation can distort the average.
• Stable story point scale: Velocity only makes sense if your team keeps the same definition of a story point over time. If you recently changed your estimation approach or reference stories, calculate velocity using only sprints with the new scale.
• Completed work only: Count only stories that meet your team’s Definition of Done. In-progress items should not be included in the total points until they are truly complete.
• Representative sample of sprints: Use several recent, “normal” sprints. Extremely unusual sprints (e.g., major outages, large training events) may need to be treated as outliers and excluded.
• Not a performance score: Velocity is a planning tool, not a way to compare teams or judge individual developers. Different teams use different story point scales, so comparing “Team A delivers 50 points” vs. “Team B delivers 30 points” is misleading.
• Forecasts are approximate: The backlog size, team composition, technology stack, and domain complexity can all change. Treat any forecast based on this calculator as a best-effort estimate, not a fixed commitment.
• Does not capture quality or outcomes: A high velocity does not automatically mean high value. Bugs, rework, and low-impact features may all contribute to points but not to meaningful outcomes.

Used thoughtfully and in context, velocity can support more realistic conversations with stakeholders. Used as a rigid target or performance metric, it can drive unhealthy behaviors such as inflating estimates or cutting quality to “hit the number.”

Good Practices for Using Velocity

To get the most out of the calculator and your velocity metric, consider these practical tips:

• Recalculate regularly: Update your inputs every few sprints so that your velocity reflects the current team and context.
• Use ranges, not absolutes: Look at minimum, maximum, and median velocities over the last few sprints to plan within a sensible band.
• Discuss context in retrospectives: When velocity jumps up or down, explore why. Did estimation change? Was there unusual time off? Did you tackle especially simple or complex work?
• Combine with qualitative insight: Pair the numeric output with the team’s judgment. The people doing the work can best assess whether a forecast feels realistic.

When you treat velocity as an input to collaborative planning rather than a target to hit, it becomes a useful, low-friction tool for aligning expectations and guiding delivery.