There are certain questions that usually surface in almost every project regardless of the type, domain considered, the Devops toolchain, technology used, complexities associated, or strategic significance. These questions are:
- When will the project be completed?
- What are the items you can deliver by the end of the project?
- What are the items the team can take for the forthcoming release or iteration?
These questions fundamentally boil-down to the schedule of the project, and what and when the team can deliver over this schedule. As you can see, the first question is about the duration of the project, the next is about scope, and the final one asks about plans to be delivered.
In Agile approaches, the concept of agile in velocity helps to address such questions. In this piece, I will start with the basics and dive a bit deeper to help you understand this concept. Towards the later part of this article, I will show you how to calculate velocity with MS Project. I will conclude with certain key characteristics.
Basics of Velocity
Velocity is the measure of product backlog items (PBI) delivered in an iteration. It’s the rate at which the PBIs are delivered, validated, and accepted according to the definition of “done,” per iteration. In other words, you can say that velocity is a measure of a team’s rate of progress. You sum up the PBIs delivered and you get velocity. If the item is not completed, it won’t count toward velocity.
The PBIs in a backlog can be features, bugs, enhancements, spikes, and refactoring, among others. You may consider all of these as part of velocity or decide to include some. Irrespective of the decision you make along with your team, it’s important to always maintain transparency on this topic.
Let’s explore an example to understand velocity better. Let’s say that in an iteration, your team delivered PBI-10, PBI-11, and PBI-3, which are estimated at 3, 8, and 5 story points, respectively. Velocity for the iteration would be 16 or 16 story points, as calculated below.
Velocity = Estimate for PBI10 + Estimate for PBI11 + Estimate for PBI3
Velocity = 3 + 8 + 5
Velocity = 16 (or 16 story points)
If you have an incomplete item, it won’t be considered for velocity calculation. For example, if PBI-11 remains incomplete at the of the iteration, the velocity will be 8 or 8 story points.
So, how does velocity help in answering the questions raised earlier, those of when the project will be complete and what items can be delivered?
Going back to our example, let’s assume the product backlog has 200 points worth of work, your velocity is 20 points per iteration, and each iteration has two-weeks duration.
Number of iterations needed = 200 / 20
Number of iterations needed = 10
Velocity in Ranges and Confidence Levels
It’s possible that velocity can fluctuate for a team over the duration of a project or release. Considering our previous example, it can be as low as 15 (minimum) or as high as 25 (maximum).
No one exactly knows what the future entails. There can be inclusion of new high priority items, a change in a 3rd party component which introduces a number of bugs, or changes in team members for the project, etc. Hence, it’s a good practice to calculate the velocity range, in place of thinking of it in absolute numbers. For example, you can say that the team’s velocity range is between 15 to 25 story points. With this approach, you are conveying that it’s an estimation and nothing is absolutely certain.
Next, let’s see how the duration changes with range in velocity numbers. With a velocity of 15, you will be needing around 14 iterations to complete (200 divided by 15 and rounded it to 14) the backlog items, whereas with a velocity of 25, the team will be needing just 8 iterations to complete the project (200 divided by 25). In the first case, it will take seven months to complete the backlog. Whereas in the latter case, it will take four months.
Why the Term “Velocity”?
As I teach and interact with Agile practitioners, I get asked about the terminology of “velocity” often, and why it’s not called “speed”? After all, it’s the rate of progress or the items a team has completed in an iteration, which, in a way, informs the speed of delivery.
There is a subtle difference between speed and velocity. Speed is a scalar concept, whereas velocity is a vector concept. Speeds tells how fast you are moving or covering a distance, whereas velocity tells how fast you are moving in a particular direction. Speed is direction agnostic, whereas velocity is direction aware.
Some may also ask, what direction is the team moving towards when the term “velocity” is used? The direction is propelled by the product vision. The vision of the product (or service, or result), to be delivered by the project, is outlined in the beginning stages of the project. Vision tells us for whom the product is being built, what purpose it’s going to serve, and what benefits it will deliver with one or more compelling differentiators. With every iteration (or Sprint, if considering Scrum framework), you are moving one step closer to this vision of the final product. Metaphorically, velocity is an apt term in place of speed.
Estimating Velocity
In our first example, we saw a velocity of 20. You might be wondering how I arrived at this number? This question leads to velocity estimation. Velocity can be estimated in a variety of ways. Let’s check a couple of them.
Using Historical Information
Historical information can be gathered from similar, previous projects in the organization. When you consider historical information, there should be little (or almost no) variations among team capability, technology and domain used, product owner involvement, etc. This technique is useful when your team is totally new to the project.
There can be drawbacks with this technique because it’s not the current team’s own data, and when actual velocity comes up, estimated velocity may not match with historical information. One could say that using historical information is a type of Analogous Estimate.
Observing Actual Velocity
In this approach, iterations are actually run to determine the velocity. The team usually runs at least three iterations and then determines the average velocity.
Compared to the previous approach of using historical information, velocity is calculated actually using the real data. There can be drawbacks to this approach, such as business executives finding it difficult to wait for at least three iterations to get an estimate, or a duration estimation needed even though the project may not be executed immediately. In such a case, you can have a forecasted velocity.
Whatever approach you may take to estimate the velocity, following are some practices worth noting:
- Discard historical information when you find the actual velocity.
- Calculate the average velocity, but communicate in ranges.
- Update the velocity at the end of every iteration.
Working with MS Project Agile
Both Scrum and Kanban don’t have any concept of velocity as a practice or a framework concept, but velocity is a widely used metric by many Agile teams and many software tools. MS Project software, which supports both Scrum and Kanban, doesn’t have velocity as an explicit metric. However, you can easily determine velocity with few customizations.
