Velocity is an important metric in scrum. Unfortunately, the term is often misunderstood.
It’s important to understand what velocity in scrum is, when and how velocity is useful, and why misapplying it actually puts the performance of Agile teams at risk.
Everything you need to know about velocity in scrum:
- What Are Scrum Metrics?
- What Is Velocity in Scrum?
- How To Calculate Velocity in Scrum
- Successfully Using Velocity in Scrum
- Final Word on Velocity: Useful or Useless?
What Are Scrum Metrics?
Scrum metrics are specific KPIs that scrum teams use to measure performance in terms of project delivery, ultimately calculating the effectiveness and deliverables of the team.
Common scrum metrics include:
- Velocity
- Escaped defects
- Time to market
- Customer satisfaction
- Sprint retrospective
- Team satisfaction
What Is Velocity in Scrum?
Velocity is a scrum metric that measures the rate at which development teams deliver business value in terms of story points. It indicates the average amount of the product backlog that is turned into an increment of a product during a scrum team’s sprint.
The bottom line: velocity measures how well a scrum team is working together, and it is used to help a team make commitments on what to deliver in a sprint.
What is the Formula to Calculate Velocity in Scrum?
The formula to calculate velocity in scrum is the total number of story points completed, divided by the time (such as the number of sprints).
The team should not include any incomplete or partially completed work when calculating the velocity as it can create confusion and prevent accuracy in the estimation. The only stories included in the calculation should be those marked as “Done.”
Teams cannot estimate velocity based on only one sprint. Instead, they should use the last 3-4 sprints to calculate a more accurate velocity of the team.
Example of velocity in scrum:
Sprint 1:
- User Story 1: 6 story points. Completed.
- User story 2: 8 story points. Completed.
- User story 3: 4 story points. Not completed, rolled over.
- User story 4: 6 story points. Completed.
- Total completed: 20 story points
Carry out this same process for the following 2 sprints to arrive at:
- Sprint 2: 16 story points completed.
- Sprint 3: 18 story points completed.
Then average these numbers:
20 story points (Sprint 1) + 16 story points (Sprint 2) + 18 story points (Sprint 3) = 54 story points.
54 story points divided by 3 sprints = Velocity of 18.
The Root of Velocity Confusion: Story Points
When there are disagreements about velocity, both how to define it and how to use it, the issue is usually centered on the story point. A user story states what the objective is and what acceptance criteria are needed to prove that the work is complete and acceptable.
Story points are measurements of relative estimation at the amount of work needed to complete the story. To ensure success, scrum teams need to discuss and assign story points to ensure everyone is on the same page.
Successfully Using Velocity in Scrum
Velocity is commonly mistaken to be a way to measure the successful output of the team, with the incorrect assumption that increasing velocity equates to an increase in speed or output or both.
In reality, velocity is more like a measurement of a team’s rhythm and should be used to monitor team health.
You want velocity to be stable. A team’s velocity number offers insight into the personalities and experiences of individual team members and how well they are working together, the nature of the software being developed, and the environment in which the team operates.
Once a good rhythm is achieved, you want to do everything you can to prevent disrupting that rhythm. If the velocity is highly volatile, you want to identify what is preventing the team from gelling and achieving consistency.
Fluctuations in velocity
Fluctuations in velocity from sprint to sprint are to be expected in the first few iterations. This is because a new team takes time to find a rhythm. This is also likely to happen when significant staffing changes occur within a team.
In most situations, velocity tends to stabilize after three iterations on a self-managed and well-guarded team (that is, guarded from distractions and from work that is not committed to the sprint).
Velocity can fluctuate based on any of the following:
- Team size
- Project complexity
- Ability for team to focus on Scrum activities and stories
- Consistency in team membership
- Level of engagement from Product Owner
- Backlog health and definition
- User story health and definition
- System outages
- Unexpected absences in the team
Velocity can shine or suffer depending on how many of the above variables are in play on a given project.
Pitfalls in Utilizing Velocity in an Organization
Unless they understand the concept of velocity and how to measure it for their particular environment, organizations can stumble with velocity in numerous ways. Common mistakes include:
- Tying velocity to individual employee performance, forgetting that it’s a team measurement impacted by numerous variables.
- Viewing velocity as a measure of speed and ignoring the levels of complexity that can affect it.
- Expecting velocity to continually increase over time. As long as the team is producing at a high level, velocity should stay consistent.
- Comparing the numeric velocity of teams against each other to determine which teams are performing the best. Velocity between teams will be different.
Final Word on Velocity: Useful or Useless?
In the vast majority of organizations where velocity is treated as a measure of team quality and project complexity and not as a measure of individual accomplishment, velocity is a useful metric.
Some ways velocity can be useful to an organization include:
- Indicating functional health of the team and the processes it follows
- Determining how much complexity a team can commit to when planning a sprint
- Identifying and removing obstacles that affect velocity
- Identifying training needs
- Adjusting project scope and business priorities, and forecasting major release dates
- Resource and project planning
- Boosting team morale when it’s stable
Organizations that get the most from their velocity metrics adhere to the following dos and don’ts:
- Do groom the backlog regularly (2–3 times per week is not unusual).
- Do use velocity to demonstrate predictability and reliability to stakeholders and executives.
- Do use short sprints and small-sized user stories and keep a fail-fast mentality.
- Do estimate story points with the whole team, not just a few representatives.
- Do use velocity to identify obstacles.
- Do have team building events like happy hour — velocity is seated in team dynamics.
- Don’t use velocity to stack-rank employees or rate team performance.
- Don’t skip Scrum ceremonies like the sprint retro, where velocity is used to identify problems.
In the end, velocity is a valuable metric that is often misunderstood. By understanding how it is derived and what factors can cause it to fluctuate, measuring velocity can be of tremendous value to every organization employing Agile/Scrum practices.
If you’re looking to realize the full benefits of scrum and enterprise agility, creating lasting change within your teams and driving lasting agile capability growth for your organization, AIM Consulting‘s experts can help.
Insights By
Need Help Realizing the Benefits of Scrum?
We are technology consulting experts & subject-matter thought leaders who have come together to form a consulting community that delivers unparalleled value to our client partners.
