## Monday, March 16, 2020

### Agile Asanas: Key Guidelines to Follow for Velocity (1)

Recently, I wrote an article Understanding Velocity in Agile Approaches with MS Project, where the foundational concepts of velocity have been explained first followed with a bit deeper dive into this concept. I’ve also explained a practical hands-on approach to determine velocity with a software tool.

In this Agile Asanas series, we will check-upon a few key guidelines while using velocity in Agile approaches. This is in continuation of Agile Asanas series. In the earlier part, we saw a completely new concept of Naikan and its applicability.

You can read it here: Agile Asanas: Using Naikan as an Agile Practice

*********

Velocity is a useful metric followed in many Agile teams and the calculation for it is quite plain and simple.

Velocity is the total story points (SPs) delivered by a team in an iteration or Sprint. For example, if a team completes 20 SP worth of features in an iteration, the velocity of the team for that iteration is 20.

However, many teams use velocity wrongly in a number of areas. In this post, I’ll outline a few which I see frequently, e.g., comparing velocity of one team with another, which is a big NO in Agile. So, let’s see the guidelines for Agile teams, if you are using velocity as a metric.

Guideline – 1: Don’t compare velocity of one team with another

You compare things which are comparable, e.g., you can say one runner is faster than the other runner, one is a better speaker than another, one vehicle is producing better fuel efficiency than another or equipment is producing more outputs than another. You can’t just compare things which are no way comparable, e.g., velocity of the teams.

How?

Let’s say a team (Team 1) completed 3 features estimated at 5SPs, 8SPs and 3SPs in an iteration. Hence:

Velocity for Team 1 = 5 + 8 + 3 = 16

Now, let’s say another team (Team 2) completed 4 features estimated at 3SPs, 2SPs, 5SPs, 8SPs, respectively. Hence:

Velocity for Team 2 = 3 + 2 + 5 + 8 = 18

Next, the question which is usually asked is this:

Is Team 2 doing better than Team 1?

No. Because story point – the unitless measure used for the features – is a form of relative estimation. And it’s subjective to the team.

To know more about story points, refer:
Project Estimation with Story Points in Agile Development

A team which has been working for a long time on a project may estimate a feature at 3 story points (SPs), because they are quite familiar with the project. However, the similar feature by another team can be estimated at 5 story points or 8 SPs or even 13 story points. Because they are learning on a new project.

It is also possible there can be dependencies, compliance related work or external risks which may increase the estimate to 8 or 13 story points, for another team. Hence the team estimating a feature 8 SPs is no way comparable with a team estimating at 3 SPs.

Guideline – 2: Give ranges of velocity in your estimation, in place of absolute numbers

The first and foremost problem when you give an estimation in absolute numbers is this: estimates usually becomes commitments. Because it becomes a commitment, you will be required or at least expected to meet that commitment.

Another problem with absolute estimation is this: it becomes a benchmark to meet, if you meet it once! This will be shown to you, because you have earlier done so.

A team goes with Agile approaches, when there are uncertainties in technology, requirements or platforms. As there are many uncertain things, agile is both iterative and incremental in nature.

To know more about iterative and incremental developments, refer:
Why and When To Go For Agile Life Cycle

Hence, in an uncertain environment, it’s futile to give an absolute number. For example, let’s say a team has these velocity measures:
• Iteration 1: Velocity = 12
• Iteration 2: Velocity = 16
• Iteration 3: Velocity = 17

A histogram representation is shown below.

Next, many times, I’ve seen teams are enticed to give an average velocity, i.e., (12 + 16 + 17)/ 3 = 15. But what happens if the team has less velocity in the next iteration?

Let’s say for the next iteration the velocity comes as:
• Iteration – 4: Velocity = 13
This is shown in the below figure.

You had earlier communicated the velocity (average one) to be 15. Now the velocity has come down to 13. It’s likely that your management will ask questions. And of course, it also looks bad.

What should you do?

You should communicate the velocity in range, i.e., 12 to 18:
• 12 as the worst-case scenario.
• 18 as the best-case scenario.

With this approach, other stakeholders realize that velocity measure given is not a commitment, but a range. And if you don’t meet the earlier one given, nobody will complain or ask questions, because they know it’s in ranges, not absolute numbers.