In Scrum and other Agile project management frameworks, velocity serves as an Agile metric used to estimate the amount of work a Scrum team can complete within a specific time frame, typically a single sprint.

You can express velocity in story points, which are units that measure the complexity, risk, and uncertainty of tasks. Unlike time-based metrics like hours or days, story points offer a more nuanced way to estimate work.

For example, consider a user story when developing an application login screen. The team could assign this task a story point value of 3 based on its perceived complexity and the effort to complete it. Integrating a complex payment gateway could receive a value of 8 due to higher complexity and potential risks.

Many factors affect the number of story points a team member can complete during a two-week sprint, including individual experience, task complexity, and team dynamics. New Scrum teams usually average 5–10 story points per person per two-week sprint.

Understanding the team’s velocity can help with continuous improvement. It allows teams to forecast future sprints, plan projects, and set realistic goals. This metric helps develop a stable work rhythm, predict project timelines, and manage stakeholder expectations. It is also crucial for effective sprint planning and managing stakeholder expectations.

You typically calculate sprint velocity at the end of each sprint by totaling the story points or other units of measurement for all fully completed user stories.

Here is the step-by-step process of how to calculate velocity in Scrum:

1. Plan a sprint

Before a sprint begins, outline and assign points to all the user stories in the product backlog. For instance:

• Assign user authentication: 5 points

• Add payment gateway integration: 8 points

• Implement search functionality: 3 points

• Develop a user profile page: 13 points

• Implement email notifications: 2 points

• Optimize database queries: 21 points

• Create an admin dashboard: 5 points

The team should commit to completing user stories in the upcoming sprint based on the average velocity from previous sprints and other factors, such as holidays or external dependencies. For example, if the average velocity is 15 points with no holidays or external dependencies, the team could commit to user stories totaling around 15 points for the next sprint.

2. List completed user stories

Create a list of all the fully completed user stories at the end of each sprint. These should be stories that have met their acceptance criteria and that the Scrum Master and Product Owner have approved.

If a user story is 90% done, it is not fully complete. The team should move it to the next sprint and re-evaluate the points based on the remaining tasks.

3. Check story points

The team should have already assigned story points to each completed user story. If story points need re-evaluation, this is the time to do it.

For instance, let's say the team has completed three user stories in the current sprint—assign user authentication, add payment gateway integration, and implement search functionality. You could assign those tasks with the following story points:

• Assign user authentication: 5 points

• Add payment gateway integration: 8 points

• Implement search functionality: 3 points

4. Sum points to find velocity

Next, you must total the story points for all the completed user stories. The sum of the story points represents the sprint velocity.

In the above scenario, the total would be 5 points + 8 points + 3 points = 16 points, which is the velocity for this sprint.

5. Average velocity

Calculating the average sprint velocity over the number of sprints the team completes can provide a more reliable measure for future sprints. This measure benefits newly formed teams or those that have changed in size or structure.

For example, if the velocities for the last three sprints were 14, 16, and 15, the average velocity would be (14 + 16 + 15) / 3 = 15 points.

Various factors can influence scrum metrics and velocity. Understanding these can help in planning and continuously improving the team’s performance.

Team size and skill level

The number of individuals on a development team and their respective skill levels can influence the work the team can complete during a sprint. A larger team can complete more story points in a sprint. However, more people can lead to high communication overhead and coordination challenges.

Conversely, a small, highly skilled team could outperform a large, less skilled team by efficiently handling complex tasks.

Team stability and experience

When Scrum team members work together for multiple sprints, they'll likely iron out many of the kinks that hinder new teams. They'll have established communication patterns and know who is good at what.

These teams have shared experiences to draw on when problems arise. This familiarity can significantly improve velocity.

Complexity of user stories

A sprint filled with complex stories will usually result in a low velocity. The velocity figure will be misleading if the complexity doesn't accurately reflect the assigned story points.

To maintain a consistent velocity, some teams aim for a balance of "quick win" tasks and more complex tasks within a sprint.

External dependencies and constraints

If your team relies on another team to complete database updates or API integrations and that team runs late, it can directly lower your team's velocity. Being aware of these dependencies and planning for them through effective inter-team communication can mitigate negative impacts on velocity.

Likewise, public holidays or mandatory company events should be factored into sprint planning, as they reduce the available working time.

Understanding your team’s sprint velocity becomes a powerful tool for several aspects of sprint planning and project management, including:

Estimating future sprints

Knowing your team’s average velocity helps eliminate guesswork and measure sprint velocity accurately. If your team's average velocity for the past three sprints has been 50 story points, you have a data-backed baseline for planning its next sprint. If your next sprint backlog has roughly 50 story points, you’re making a reasonable commitment.

Forecasting project timelines

Stakeholders rely more on data-driven estimates than guesses or wishful thinking. For instance, if your project backlog has 200 story points and the team's average velocity is 50 story points per sprint, you can confidently forecast that the team will likely need around four more sprints to complete the project.

Identifying overcommitment and undercommitment

A team's velocity suddenly dropping to 30 story points or skyrocketing to 70 is a red flag. A consistent drop might mean the team feels overwhelmed, and a rise could mean under-challenged team members. This knowledge allows you to make real-time adjustments, such as reassigning tasks or reconsidering sprint goals.

Tracking improvement and iterative progress

Tracking velocity over time helps you understand whether your team is becoming more efficient or ongoing issues need attention. If your velocity climbs from 40 to 60 over several sprints, it's a sign your process improvements are yielding results.

Jira offers a velocity chart and a variety of other Agile reports, so your software team can easily track velocities, predict future performance, and make sprint planning easier. It's a one-stop tool for visualizing how much work your team can handle, letting you set more accurate future sprint goals.

Moreover, Jira also offers Agile metrics, contextual insights, reporting, and project management features your team needs to improve planning and performance.

Is sprint velocity in Scrum the same as productivity?

No, velocity in Scrum is not the same as productivity. Velocity is a metric primarily for planning and estimating how much work a team can handle in future sprints.

Productivity is usually a broader measure that can include factors such as the quality of work, efficiency of processes, and value to the business.

How can a team improve its sprint velocity?

Teams can improve velocity by holding regular retrospective meetings to discuss what went well and what didn't and plan improvements for the next sprint. Minimizing context switching—reducing frequent shifts between different tasks or projects—can lead to a higher and more consistent velocity.

What are the limitations of using sprint velocity in Scrum?

While velocity is a valuable planning tool, it has limitations and shouldn't be the sole performance metric for evaluating a team. Consider tracking other Agile metrics for a more comprehensive view of team performance.

One significant limitation is that velocity doesn't measure the quality of work or the delivered business value. It's a quantitative measure that doesn't account for the qualitative aspects of individual user story complexity.

Velocity is team-specific—it's not a measure for comparing the performance of different teams. Each group within a team may work differently, resulting in varying velocities. A lower overall velocity does not automatically mean that one team is less successful than another.