Velocity – this is one of the very common terminologies “used” & “misused” in the Agile world. Let me take a chance to write about it.

Before getting into Velocity-related discussion, let’s first talk about estimation, which is a fundamental thing in velocity calculation.

**My experiment with Human Accuracy**

Our typical thinking is that estimation must be accurate. It is an Oxymoron. The estimate cannot be accurate; it must be an estimate.

My experiment about Human accuracy. Humans cannot be accurate. For example, several times, I asked people “what is the exact height of your neighbor in Centimetres?”. No one gave an exact answer. When there is a group of 10 people, 10 gave 10 different answers. How can EXACT height be 10 different numbers? My learning was “Humans cannot be accurate”.

HOWEVER, humans can relate very well. When I asked the question “who is taller out of these 3 people?”, I got the right answer ALL THE TIME. How come? We just didn’t go by measurement, but by relative theory. If you want, you try the same with anybody, you will get the same results. Simply because we are human 😊.

Like this, I have done multiple experiments on accuracy. It’s proven that humans cannot be accurate, but can relate very well.

Why am I bringing this here? Because estimation and story point has a connection with this. So, remember – HUMAN CANNOT BE ACCURATE, BUT CAN RELATE EASILY.

**User Story Estimation**

Estimation can be done at multiple levels –

- Estimate Epics
- Estimate Features
- Estimate User Stories
- Estimate tasks

Task level estimates are too detailed and it’s typically in hours. Since humans cannot be accurate, it’s not good to go ahead with task-level estimates. Even if you decide to use this, you cannot use this for long-term product development work. It may work for a max of 2 weeks iteration.

Now, the next level estimate is the “User Story” estimate. This is where the Story Point measure comes in. Since humans cannot be accurate, it’s better we remove the units from the human mind. For ex., hours, days, etc. Then, how do I estimate? We also learned that humans could relate. Let’s relate between user stories.

### Factors for Estimating the user stories

Using Story points. To use story point estimation, let’s use the following factors that can influence your estimation.

- Size of the work
- The complexity of the work
- Knowhow of the work by the team

**Identify Reference User Story**

Before estimation, to relate, you need a “Reference” user story. Pick 1 user story, which is

- Very small in terms of work size (“can complete in a very short time, say a day, for example”)
- No complexity at all (“very simple work”)
- I know it very well (“I have done this several times”)

Mark such a story as a reference story with Story Point “1”. You are going to use this as a reference for the rest of your estimations, maybe for a year or so. Hence, picking the right reference is key.

**Relative Estimation**

Most of the industry uses modified Fibonacci for relative estimation – 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞

Many people ask me this question – why Fibonacci?

### Why Fibonacci?

Here are a few reasons, why Fibonacci is powerful in the relative estimation

- The size or complexity of the problem is not in a number series of say 1 to 10. It is at times exponential. If you look at the above Fibonacci series, they are incremented by 60%. Differences between 2 and 3, 3 and 5, 5 and 8, 8 and 13 are approximately 60%. Hence, it allows you to size differently based on high size/complexity.
- Why can’t we use the number series 1 to 100? The moment you give a big list of numbers, there can be a detailed discussion on whether the size is 7 or 8 OR 12 or 13. The objective story point size is not to be accurate. Remember, we cannot be accurate and our intention in story point sizing is not to be accurate. We quickly choose one of the numbers and size the story.

We now understand how to estimate.

**Who will estimate?**

The entire team. The power is Agile is the team, hence the whole development team should estimate using the above Fibonacci series.

**Estimation steps**

- PO explains the story and the development team members clarify their queries.
- Each person picks a (relative) number from the Fibonacci series.
- All of them show up at once so there is no influence between team members
- If everyone aligns, then they choose the number. If there is a difference, then the lowest and the highest get into a discussion on why they estimated that. Others listen. This is time-boxed – say 1 or 2 minutes.
- Again, everyone estimates, and again the discussion if there is a difference.
- Converge when all choose 1 number OR they have chosen 2 numbers that are next to each other – say 5 & 8, 8 & 13, etc. Choose one of them in such a case based on the majority.
- If the difference continues, that means there is some clarity issue in the user story. Mark it for future

## What is the velocity in agile?

The English definition of “velocity” is “The speed of something in a given direction”. Simple definition in the agile world is “Average story points delivered in the last few iterations”. This means, the total number of story points that the team delivered in every iteration.

### How to calculate Agile Velocity?

To measure Agile velocity, you need to execute at least 5 iterations in an agile / scrum way. Once done, you can measure the past velocity by having the story points assigned to the user stories.

Assume that your team has delivered 8 stories each estimated in story points as – 5, 3, 5, 2, 5, 2, 3, 5. The total story points accomplished by the team is 30. In the second iteration, the team has delivered say 35 story points. Once you are done with say 5 iterations, take an average.

Iteration 1: 30 Story points

Iteration 2: 25 Story points

Iteration 3: 34 Story points

Iteration 4: 35 Story points

Iteration 5: 36 Story points

**There are 2 ways you can calculate Agile Velocity – Agile Velocity Formula.**1. take an average of all the 5 iterations. Average = (30+25+34+35+36) / 5 = 160/5 = 32 story points.

2. Neglect the first 2 iterations due to variations in data. Take an average of the last 3 iterations. Average = 34+35+36 / 3 = 35 story points. My preference is this.

Now, you are ready to use velocity for your future planning.

#### Is Agile Velocity a productivity measure?

Agile Velocity is not a productivity measure, it’s a predictability measure for the team.

I have seen Leaders drive velocity and pressurize teams to increase velocity, say from 40 to 50 story points. An increase in velocity is not a bad thing, in fact, it’s a good thing. However, the goal of velocity measurement is not to increase velocity.

**How do we use this for predictability?**

Assume that your team’s velocity is 35 story points, as given in the above velocity. You can use this information to plan for a longer term. For ex. if the entire backlog to be built is of 500 story points. You can easily calculate how long it will take to accomplish by the same team. 500 / 35 = ~15 iterations. With this information, the team can plan better and set the right context for customers/stakeholders, etc.

**Few guidelines** to follow while calculating velocity.

- Remove outlier iterations. For ex., an iteration that has 50% capacity due to festival season. Calculating velocity based on such iterations will give you a lower velocity.
- Here is another outlier example. At times, the teams would have worked so hard to make the release happen, and, in such cases, the velocity would have been increased by 2 times. Considering this iteration for velocity calculation would unnecessarily increase the velocity, which is not sustainable.
- Calculate story points when the story is done based on User Story DOD, so the baseline tasks/definition is the same across user stories.
- Remove outlier iteration from calculating velocity.
- The whole team does estimate story points, not a few members or a few seniors estimate for the rest of the team.
- Do not use this as a productivity measure. It will be misused. Use this for predictability.

**Summary:**Story Point Estimation and Velocity are such powerful tools for Agile teams. Using them effectively will make life much simpler and more predictable. Using it wrong will lead to wrong results.