Velocity: An Elusive Metric in Scrum
02/07/2017 | Delivery Leadership
When I interview candidates for a position in an Agile/Scrum development project, I often ask: “What is your team’s current velocity?” The candidate might think the response needs to be a high number, but it doesn’t matter what the number is. What matters to me is that the candidate knows the number.
Velocity is an important metric in Scrum for measuring how well a team is working together. This is what I want to assess when asking this question. Unfortunately, the term has been misconstrued to mean something else: a measure of a team’s speed or productivity, often with the assumption that the number—whatever it happens to be—should increase infinitely over time.
When velocity is misused this way, it can be detrimental. For one thing, it gets discredited by the team it is meant to benefit. For this reason, it’s important to understand what velocity is, when and how velocity is useful, and why misapplying it actually puts the performance of Agile teams at risk.
What is Velocity?
Velocity has numerous definitions. It’s defined by Version One as an extremely simple, powerful method for accurately measuring the rate at which Scrum development teams consistently deliver business value, with story points, days, and hours all being acceptable units of measurement. It’s been defined by Scrum Alliance as how much product backlog effort a team can handle in one sprint, and by the Agile Alliance as the sum of effort estimates associated with user stories that were completed during an iteration.
All of these definitions have the same intent, which is to establish and measure a “constant pace” that can be maintained indefinitely, as described in the Agile Manifesto, but the difference in verbiage can lead to confusion.
Here we’ll define velocity as the sum of the story points completed per time box (such as a sprint). This definition is useful because of its simplicity. When a story is completed, its points are added to the overall velocity score; if not completed, the points are carried over to the next iteration, as in this illustration:
In the diagram above, you can visually see that velocity is the sum of all story points completed in the time boxed iteration. Note that each user story is assigned a different number of story points. These points are an estimation of the complexity involved in completing the story. Velocity then is not a measurement of how many user stories are completed, but a sum of the complexity of all the user stories together in the sprint. By calculating velocity in each sprint, an Agile team is able to monitor their ability to execute on the amount of complexity estimated iteration to iteration.
Story Points are the Root of Velocity Confusion
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 describes a well-defined piece of functionality needed in software. A well-written user story states what the objective is and what acceptance criteria are needed to prove that the work is complete and acceptable. The Scrum team needs to groom, discuss, and refine the story, then estimate and agree on the “points” each user story has. Story points are measurements guessing at the amount of work needed to complete the story. In some teams, the lead developer or manager assign points, but in my opinion this is harmful to the tenets of true Agile methodology, which emphasizes self-organized teams; therefore, the task of assigning story points is best performed by the entire team so that everyone agrees.
There are other ways to do it. Some teams use T-shirt sizing instead of points, with the complexity estimated as extra small, small, medium, large, or extra-large, but using T-shirt sizing makes it difficult to measure velocity because these measurements cannot be summed. In addition, the complexity of software development is not linear, so the difference between a medium and large T-Shirt estimate may not accurately represent the increased magnitude of effort in a software development equivalent.
One great way to estimate story points is to follow the Fibonacci sequence, where after the first few numbers, every number thereafter is a sum of the two preceding ones. For example:
In a true Fibonacci sequence, the last number would be 21, not 20 (sum of 8 and 13). Some teams might go higher, to 34 and then to 55 and beyond. However, in my experience on Agile teams, it has been standard to acknowledge that any effort greater than 20 is too large and will need to be broken into smaller stories. Therefore, 21 gets rounded down to 20 with the understanding that any number higher than 20 represents a story that is too complex to consider. The team might even have an agreement never to work a story over a certain size.
Regardless of the system used, the important thing is to focus on estimating complexity. When measuring complexity, include the level of doubt and unknowns as well the level of expected difficulty. Don’t be concerned about estimating the number of hours to complete the story.
What Is Velocity Used For?
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 is 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.
A study conducted at the University of Ljubljana demonstrates that there will always be fluctuations in velocity from sprint-to-sprint 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 and can shine or suffer depending on how many of these variables are in play on a given project:
- 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
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. One major mistake occurs when management ties velocity to individual employee performance, forgetting that it’s a team measurement impacted by numerous variables. Another mistake occurs when organizations view velocity as a measure of speed and ignore the levels of complexity that can affect it. Maintaining a poor backlog health from a lack of grooming the backlog and from poor team participation are also common mistakes.
One of the most common problems is expecting velocity to continually increase over time. As long as the team is producing at a high level, velocity should stay consistent. In fact, expecting velocity to increase when the team has a great rhythm already can be counterproductive to team health and put the project at risk. The math is really simple: If you instruct a team to increase velocity from 80 to 100 points because executives are measuring performance by velocity, the team can produce the same number of features, but recalibrate the estimation of story points to end up with a velocity of 100. The team might even produce slightly fewer features with a velocity of 100 because the team is now focused on passing the velocity test rather than trying to ship great software. In addition, there may be consequences to morale, which impacts commitment and actual performance.
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. Here are some ways it can be very useful to an organization:
- As an indication of 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
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.