How do you estimate the amount of work your team can realize within a sprint? Velocity is one of the most popular measures used by Scrum teams to add up effort estimates. This post intends to demonstrate how velocity can be useful during sprint planning to estimate how long the project will take to complete. We will also take a look at some common pitfalls to avoid.
What is velocity and how to measure it?
Velocity is the number of story points associated with stories a team completes during a sprint. To measure this indicator, you need to total up the number of story points delivered during the last sprints and average them. Velocity should be calculated over a minimum period of 5 sprints to get a reliable average.
Let’s say your team has the following velocity:
| Sprint 10 | Sprint 11 | Sprint 12 | Sprint 13 | Sprint 14 |
| 35 | 38 | 33 | 36 | 35 |
The team average velocity will then be 35 story points (35 + 38 + 33 + 36 + 35 ÷ 5 = 35).
How much stories a team can commit in a sprint?
During sprint planning, the team must estimate the number of Product Backlog Items (or PBIs) they will be able to complete. Velocity will help them achieve this estimation.
A team may decide to bring more PBI into the next sprint than their average velocity, in which case it must consider the risks incurred by this decision. The team must make sure this decision is aligned with the sprint goal.
The capacity
Another measure to consider during sprint planning is the capacity. This indicator is based on the team’s expected or projected future availability. By discussing its capacity, the team will be able to determine if the average velocity will be affected. For example, a vacation period could affect the capacity.
A team may also choose to take less PBI than their average velocity. Instead, they can decide to focus their effort on solving a bug or setting automated tests to make future releases
Basically, velocity should initiate conversation between team members and be used for planning purposes.
How to use velocity as a Product Owner?
The Product Owner will also appreciate the velocity indicator. Product Owner can use this indicator to better estimate and plan releases. A Product Owner must not seek to increase the velocity of his team. He should focus on the business value delivered, such as a working increment of a product.
Three common pitfalls to avoid
Although velocity is a valuable indicator for planning purposes, here are some pitfalls to avoid.
Pitfall # 1- Use velocity as a team performance and productivity indicator.
Managers can be tempted to use the team velocity as an indicator of performance or even make comparisons between teams. Velocity should support the team and help them plan better.
Pitfall # 2 – Use velocity indicator only.
Your team can have a great velocity, but does it deliver value? Mike Cohn suggest another indicator, which is a team’s ability to turns ideas into new functionality during a sprint.
Pitfall # 3 – Estimate a delivery date based on the velocity at the beginning of the project.
At the beginning of a project, a team is not at full capacity, and it needs to complete a few sprints before taking its cruising speed. Again, according to Mike Cohn, we can not expect the team to reach its full velocity before its fourth sprint.
Find out your velocity with Nutcache
Nutcache now offers a series of indicators to facilitate your planning session. Scrum teams have access to velocity diagrams.
These new indicators allow them to see at a glance their capacity. Nutcache also offers wealth of additional KPIs:
All these KPIs are now available to Scrum teams using Nutcache. Log into Nutcache to discover your team velocity.
Not on Nutcache yet?
Nutcache provides a visual, flexible and comprehensive tool for Scrum Masters, Product Owners and Teams to manage and organize work and deliver projects on time and within
Sign up now and enjoy a 14-day free trial.
