There are certain questions that usually surface in almost every project regardless of the type, domain considered, 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 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

We will be needing 10 iterations or 20 weeks to complete the work items in this backlog. If you start working on the backlog during the month of January, you will be able to complete it by end of May, which is shown in the below figure.

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 3^rd 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. You can graphically represent it as shown in the below figure.

Our velocity estimation can be refined further by looking at confidence intervals. For example, you can say the team can complete the initial 80 points with 90% confidence, whereas the next 70 points worth of work can be done with 50% confidence, and finally, the last 50 points worth of work with 10% or with very little confidence.

Why provide the confidence levels? So that work items towards the bottom of the backlog are not clearly defined and estimated, i.e., they are coarse grained, and very big–usually epics. Estimation for such work items will be 40, 80, or 100 story points. As you can see, confidence levels helps in setting proper stakeholder expectations.

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.

By way of illustration of this, we will use a Scrum framework and follow four steps.

Step – 1: Create Needed Custom Fields

Product backlog items can be features, bugs, enhancements, and even documentation related to the work. For the sake of our example, I’ll only consider the features which will be estimated in story points. In our case, we will create two custom fields:

• Feature (flag) – a Boolean/flag custom field. If yes, then the PBI is a feature; otherwise it can be any other PBI type.
• Story Points – a number custom field, as story points are calculated in numbers. If you are not going with story points, you can have feature points or simply, points.

When you create the custom field for “feature,” it shows as captured below:

When creating custom field for “story points,” ensure that the calculation for rows and summary tasks is rolled-up. This is depicted in the below figure:

Another custom field is needed for velocity calculation (a number customer field), which we’ll simply call “Velocity.” The velocity will be calculated only if the PBI is a feature and it is 100% complete. This you can translate into a formula.

Note that for this velocity custom field, the calculation for rows and summary tasks is rolled-up. This is depicted below.

Step – 2: Use the Built-In Groups and Filters

The MS Project software comes with a number of built-in groups and filters. We will take one such group, Sprint.

Before applying the grouping, we have the following Backlog with items distributed across various Sprints. You can drag and drop the backlog items and put them into respective Sprints as shown in the Sprint Planning Board view.

In the Sprint Planning Sheet view, we have the following depiction. As shown below, the items are populated with the values in the respective fields.

We have story points estimated for PBIs, and a field for whether the PBI is a feature. The PBI priority has been set with product prioritization techniques.

Apply the in-built group: Sprint, which results in the below view.

Step – 3: Calculate the Story Points for a Sprint

As shown in the previous figure for individual Sprints, the story points have been cumulatively added and rolled-up to the Sprint level. For example:

Sprint 1:

• Three features, “Log into the online trading system,” “Create a new user,” and “Buy a stock,” are estimated at five story points (SPs), 8 SPs, and 5 SPs, respectively.
• Add them together, and we have a total 18 story points worth of work.

Sprint 2:

• Three features, as well, are: “Logout of the system,” “Sell a stock,” and “Transfer a stock,” each of which are estimated at 5 SPs.
• As you add them up together, we have a total of 15 story points worth of work.

Similarly, it’s for the other Sprints and the entire product backlog, which has, in total, 208 SPs worth of work.

Step – 4: Determine the Actual Velocity for a Sprint

The final step is to calculate the velocity for the Sprint. For this purpose, we will add the velocity custom field, which we created earlier.

As the team starts sprinting and completes the features, only then will the velocity field be populated. Let’s say at the end of the Sprint, the team has completed all the features. The velocity will be 18, as shown the below figure.

Characteristics of Velocity

In conclusion, I will summarize certain key characteristics associated with velocity, as follows:

• Only completed and accepted work is counted towards velocity.
• Velocity is a measure of output (the size of what delivered, such as a 20 story points delivered). It’s not a measure of outcome (translating to value).
• It’s an empirical observation of the team’s capacity to complete work per iteration. As noted earlier, even though you use historical information, discard that immediately as soon as you have actual data to work with.
• Velocity is comparable across items for a given team on a given project. For example, while you can compare the same team’s velocity over iterations, you can’t compare two separate teams’ velocities.
• Velocity is not a measure of productivity, as that would be a trap and a subjective estimate, not an objective one.

References:

[1] Book: I Want To Be A PMI-ACP: The Plain and Simple Way, by Satya Narayan Dash

[2] Video Course: Microsoft Project Live Lessons, by Satya Narayan Dash.