Let’s begin by defining our terms. According to scrum.org, scrum is:

“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”

When we talk about scrum velocity, we talk about the number of user story points completed in each sprint. By user stories, we mean informal and naturally written descriptions of a feature in a software development project. We should write user stories from the perspective of the end-user. When measuring scrum velocity the development team uses story points. According to Atlassian:

“Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty.”

Story points in agile replaced time estimates. Waterfall and other traditional project management methodologies use time estimates. In waterfall software development project managers and owners project in weeks or days. Using agile teams have more flexibility and chances to learn from previous experience.

Scrum velocity means the number of new features a software development team can complete in a sprint. The scrum velocity metric allows teams to plan future sprints. It allows them to examine past work. They note bottlenecks and bugs that slow projects down.

Learn more about user stories and other features in the "Epic, Story, and Tasks in Agile" article.

The scrum velocity metric is a later addition to agile methodology. Velocity comes to agile and scrum from the world of extreme programming (XP). In 2000, people in extreme programming began using the term velocity. Velocity replaced “load factor.”  In 2002, scrum communities began measuring velocity as a way to refine their processes and self-regulate.

Teams use velocity along with other metrics, such as sprint burndown, and ROI (return on investment). This allows teams to plan and fine-tune their process. With constant attention to process, they can best plan and put in place necessary changes.

Read on other Scrum metrics to improve the effectiveness of your project.

In planning a sprint, the scrum master and product owner will try and estimate velocity. They will base the estimate on the team’s past performance. Newer teams usually have less velocity than more seasoned teams. Development teams deep into a project will typically have a better velocity than teams at the beginning of a project. Teams can improve their velocity by about 10% each sprint.

Measuring scrum velocity allows teams to estimate future sprints, revising the sprint plan to match the team’s capacity.

How do we calculate scrum velocity?

First, in the sprint planning meeting, the scrum master leads the team in determining how many user story points the team will aim to complete. The development team weighs in and they estimate the number of story points they will try to finish in the sprint. Let’s say the development team decides to complete 35 story points in the sprint. The number of completed story points is the scrum velocity. Scrum velocity does not count incomplete story points, even those a bit short of finished. In our example, the team completes 32 story points and pushes 3 story points to the next sprint. The team earns a scrum velocity of 32.

This number proves useful, but not as useful as the average of several scrums. Let’s imagine our software development team finishes the next four sprints with scrum velocities of 35, 27, and 38. The average of these sprints’ scrum velocity gives the scrum master and development team a better idea of how the team performs over several sprints. This enables them to plan future sprints with more insight and accuracy. More information gives the team more power.

Related post: Converting Story Points to Hours: Why Doesn’t It Work?

Software development teams can better understand scrum velocity by creating a scrum velocity chart. A scrum velocity chart allows for a quick visual comparison between different sprints. The team can map the velocity by creating a simple bar chart. The y-axis shows story points and the x-axis shows the individual sprints.

Why is velocity important in scrum?

Why do we care about the scrum velocity metric? Measuring scrum velocity allows software development teams to plan sprints with more accuracy. Without measuring scrum velocity, teams cannot engage in accurate release planning.  As teams complete later sprints they can see how their workflow changes. They can decide how many story points they can handle in each sprint. This keeps the software development team from taking on too many tasks in a sprint. Product owners can use scrum velocity to revise their delivery estimates based on the changes in scrum velocity.  Measuring velocity will help teams decide which changes are helping their processes and what is not working. 

But development teams need to take caution with scrum velocity. They should not use scrum velocity in a punitive manner. Product owners should not use scrum velocity to compare one team to another. Since scrum velocity is a subjective metric, teams should use it only to compare one sprint to another. Scrum velocity also refers to the output of the entire software development team. Scrum velocity does not apply to Individual team members. Using velocity in these ways undermines transparency. Teams that feel they are being compared in such a way will be less honest.  

Here at Blocshop, we use scrum velocity along with other metrics such as Time to market, team satisfaction,  and ROI (return on investment). These metrics form the KPIs (key performance indicators) that we implement to deliver software development projects on-time and under budget. If you would like to learn more about how Blocshop uses these agile metrics, please do get in touch.