Understanding Velocity and How It Affects Commitments | David Tzemach
Updated: Mar 2, 2022
At the end of the sprint, the team adds up effort estimates associated with user stories that meet their Definition of Done. This total sum of estimates is called the team’s velocity, which is a measurement technique that is used to measure the amount of work delivered by the team at the end of a sprint.
Example:
Why calculating velocity is worth the trouble
As I have learned over the years, there will always be team members that have something to say about velocity calculation because they cannot see the value behind it. Questions like "Why do we need to measure our work?" or "How does it add value to our effort" or "How is this useful?" are common questions often asked. These questions make sense when you are the one being measured.
Here are some common answers to address these questions:
It helps the team understand the amount of work they can carry out in a single sprint. Thus, avoiding over/under committing.
Velocity is a great planning tool for estimating the remaining work in a project, and how many sprints it will take to deliver it.
Velocity can be used as a motivating factor for a team that will want to improve its average through the project.
Velocity is the mirror for the team to understand the difference between the original estimations based on what they thought they could accomplish and what they actually delivered.
What factors influence the team’s velocity?
High or low velocity depends on several factors such as wrong initial estimations, sick team members, unplanned disturbances etc. This is the reason I recommend reviewing at least five sprints to determine the average velocity of your team. Obviously, this must be reviewed regularly and updated accordingly.
What unit is used to measure velocity?
The only rule that I have is that you will use any measurements (story points, days or hours) which are acceptable to the whole team.
Should uncompleted stories be part of the velocity calculation?
The answer is no. In Agile software development, the team’s main goal is to add real value to the customer. Uncompleted stories mean the customer will not receive functionality that he expected to receive at the end of the sprint. Therefore, it does not add any value and should be discarded from the overall velocity calculation.