Want to know how fast your Scrum team can really go? Velocity is a speedometer for your Agile project and provides unparalleled insight into your team’s work capacity. This guide will unravel the secrets of velocity in scrum, teach you how to calculate it, and show you how to use this powerful metric to predict your team's future performance.
What is velocity in scrum?
In Scrum and other Agile project management frameworks, velocity serves as an Agile metric for estimating the amount of work a Scrum team can complete within a given time frame—typically a single sprint.
You can express velocity in story points, a unit of measure for sizing user stories or tasks in terms of complexity, risk, and uncertainty. Story points provide a more nuanced way to estimate work than time-based metrics, such as hours or days.
For example, consider a user story for 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 influence the number of story points each team member can complete during a two-week sprint, such as the individual's experience, the complexity of the tasks, and the team's working dynamics. New scrum teams typically average 5–10 story points per person for each two-week sprint.
Understanding the team’s velocity can help with continuous improvement, allowing teams to forecast for future sprints as well as planning and setting realistic goals. This metric helps teams develop a stable work rhythm, predict project timelines, and manage stakeholder expectations.
How to calculate velocity in scrum
You typically calculate 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 completed work. The team should move it to the next sprint and re-evaluate the points based on the remaining tasks.
3. Check points
The team should have already assigned story points to each completed user story. If, for any reason, 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 need to 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. So, the velocity for this sprint would be 16 points.
5. Average velocity
You can gain a more reliable measure for future sprints by calculating the average velocity over the number of sprints the team completes. This measure is particularly useful for 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, then the average velocity would be (14 + 16 + 15) / 3 = 15 points.
Factors that can affect scrum velocity
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 team and their respective skill levels can influence the work the team can complete during a sprint. A larger team might be able to 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, factor public holidays or mandatory company events into sprint planning, as they reduce the available working time.
Using velocity in scrum
Once you understand your team's velocity, it 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. If your team has an average velocity of 50 story points for its past three sprints, 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 under commitment
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.
Track velocity in Jira
Jira offers a velocity chart, in addition to 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 take planning and performance to the next level.
Velocity in scrum: Frequently asked questions
Is 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 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 velocity in Scrum?
While velocity is a useful planning tool, it has limitations and shouldn't be the sole performance metric for evaluating a team. For a more comprehensive view of team performance, consider tracking other Agile metrics.
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.