Estimations have always been a critical area in business that has extreme views. On the one hand, there is a push to define micro-level estimates to build plans; on the other, there are #noestimate thought processes. The concept of velocity in agile is therefore critical to understand as, while being a form of estimation, it still tries to address the shortcomings of trying to have binding estimates.
Table of Contents
The Traditional Estimation Process
Traditionally, the estimation process considers the quantum of work to be accomplished. Then the person or team doing the work will estimate the time it will take to finish it. Often, this process breaks down the work into smaller items that are easier to estimate as they reveal the hidden complexities. Then the person estimates the time required to complete those individual, smaller work items. All such individual estimations are then rolled up to have the estimates for the entire project.
Buffers are added for any further unknown complexities or issues along the way. Often, these buffers are subjective, while in some cases, teams arrive at those buffers using some mathematical formulae.
Issues With Traditional Estimation Process
1. Typically, the traditional estimation is done based on past experiences. If the context changes and some or all dimensions of the new problem are different, such an application will result in incorrect estimations. Also, the estimator may not apply the lessons learned from past experiences.
2. Such estimations are also subjective. It depends on personal strengths and weaknesses, suffers from biases, and may ignore or underestimate the complexities, hidden or otherwise while estimating.
3. Such an estimate will also consider the ideal time for the tasks. However, in real life, there will be constraints and challenges on the time availability of the people working on the tasks. Given such challenges, the estimation may not hold.
Agile Estimation
Agile changed how teams approached estimation. The traditional estimate has the scope as the foundation of the estimate, and people define the time and resources required to complete the scope.
With agile frameworks like Scrum, the timeboxing concept changed the estimation foundation. Now, agile teams fix the timebox, look at the availability, and then define how much work can be accomplished during the timebox.
Agile estimations use relative sizing and story points to define the quantum of work.
The primary difference is that this kind of sizing doesn’t represent the time required to complete the task, but the perceived value or complexities of that task, depending on how the team defines the size.
The amount of work the team completes is the velocity of the team.
Origins of Velocity In Agile
While definitive historical timelines or references are unavailable, the XP (Extreme Programming) first used the concept and term. After that, however, Scrum picked it up, and it became the benchmark that teams started using to guide their planning efforts.
Kanban has a similar concept of throughput.
But for the remaining part of the article, let’s assume that we are working with Scrum.
Definition of Velocity
To understand velocity, we first need to understand the story points. My earlier article on Agile Estimation provides a detailed understanding of various aspects related to story points and how estimation works. In another article, you can also read about user stories, which are the unit of agile estimations and story points.
Velocity is the average total story points completed in all previous sprints.
Let’s see an example.
For the initial sprint, we completed user stories worth 100 story points.
For the second, our sprint velocity was 90.
For the third, the team velocity was 120.
Our velocity is (100 + 75 + 130)/3 = 305/3 = 101 (For all the maths wizards, we can safely remove decimal points from consideration).
The amount of story points the team can complete in a sprint depends on a few factors;
1. The complexity and the size of the work. Some might want to argue that the story points cover both these, but depending upon how teams assign the points, complexity, and size may still impact the average velocity across sprints. Also, teams may uncover additional complexity mid-sprint.
2. Availability of team members to do the work. While the team size of the Scrum team may be fixed, people might not be available consistently for various reasons.
3. The extent of technical debt. If to complete a user story, the team first needs to handle the technical debt accumulated over previous sprints; it may impact the work the team finishes.
4. External dependencies may also impact the velocity. While in theory, the Scrum team should be self-sufficient to complete all the work required to achieve the sprint goal, in real life, that may not always be the case.
How to use velocity?
Based on the discussions above, we can identify certain characteristics of velocity;
1. It changes over time and depends on various reasons.
2. Given this dependency, velocity is not a measure of efficiency.
Many people mention velocity as an agile metric. Metrics are used for measurement. Velocity is not a metric you should pursue in that sense.
Rather, velocity is a guideline that provides a tentative idea to the team about how much work they should consider for future sprints.
It is not a commitment to finish the work.
The team will delve deep into the work they have planned based on the velocity, and if additional complexities are uncovered, it may impact the sprint outcome.
How Not To Use Velocity?
Beyond its use as a guideline for planning the quantum of work, velocity doesn’t have much use.
Many would have differing views on the above statement. However, it is based on the following;
1. Even if teams achieve a consistent velocity, it may not improve the outcome. It may indicate consistency, but it does not impact the value delivered to the customer, which is the highest priority of any agile team.
2. Since it is not an indication of efficiency, you may not use it to identify the areas of improvement. Each team will have a different velocity, possibly even for a single team; the velocity would change over a period of time. Hence it doesn’t tell us much about anything.
3. Also, velocity is not a commitment to deliver the work. Teams need to plan their work based on the velocity, but they don’t commit to delivering it at that rate. They may choose to adjust the velocity based on the actual progress made by the team.
Conclusion
In summary, velocity is a guideline to help teams plan their work. It is not a commitment to delivery.
If you use velocity for anything above, you should evaluate the problem you are trying to solve and see if a better solution is available.
