The one major flaw in calculating team velocity:

It's in the formula.

Business, the major stakeholder and sole customer to a product team, rightfully wants to use estimates to forecast how much "work" can a scrum team deliver.

A scrum team also would like to implement continuous improvement using feedback loops from each sprint. After all, one cannot improve what one cannot measure. How do they go about doing that? What standard metric can be meaningful?

A scrum team cannot just say we deliver "work" and stop. It would be nice to have a unit of work instead of just work. Furthermore, deliver "work" in what period of time? For instance, when you measure a car's performance, you measure its velocity or speed, both, distance and time and not just time.

The problem with using only time as the estimation unit is that we cannot properly calculate the velocity or speed of a team. This is because the mathematical speed formula includes both distance and time. Distance in the numerator of the equation, and time in the denominator (speed = distance / time).

We already have the denominator, a well defined unit of time, in Scrum, that is the Sprint. Where is the numerator, the "distance"?

If we don't have both units of measurement well-defined and standardized, it is impossible to calculate the velocity of a team. We must have a numerator, the size of the work standardized and well-defined in addition to time or hours.

This is where Story Points come to the rescue. An excellent candidate as a standard unit of size for work. It works great because it's relative to other work, focused on the work itself, fixed, accurate, and can be agreed upon by multiple individuals.

Therefore, Story Points can fill in the missing numerator in the speed formula so the team velocity can be calculated. So now we have both the numerator and the denominator of the speed formula.

Story Points must strictly measure work and not time

A common pitfall when a team tries to estimate using Story Points is that they tend to slip back and base their Story Point estimate on time instead of purely on the size of the work.

This is usually the biggest hurdle in transitioning into using Story Points estimates. It takes some reconditioning. However, it's also one of those "Aha" moments once someone gets it and starts separating in their head the "size/complexity/volume" of work from "time/hours/fast & furious".

Here's an example to help separate the concept of size from the concept of time. I find using distance to be a good metaphor because after all, distance is part of that equation (numerator) in determining speed.

Say we have a team and we're looking at covering the distance between London and Paris. It's easy for the team to agree that the distance between these two cities is "smaller" than the distance between Paris and Tokyo.

Heck, they can even agree, with ease and consensus, that these are not walking distances either, from a complexity perspective that is. In addition, everyone can come to a quick agreement that the distance from Paris to Tokyo is much bigger and that there are more navigation points or "risks" along the way. So they can say that the "size" of it is simply "bigger" as compared to Paris-London.

Notice that in the above example we did not mention time or hours. The discussion among the team members was focused on distance (the work), the risks, navigation points. It was focused on what makes the travel "bigger". They can easily agree on technical details without considering time. And then to arrive at the size, they used relative distance comparisons to other destinations.

On the other hand, time is a whole separate concern and has nothing to do with the size/complexity/volume or agreeing technically on the nature of the work. Once we move on to the time discussion, it's a whole different story (no pun intended).

When it comes down to time, maybe one team member has a bicycle, and therefore, it will take him or her much longer to cover the distance than for example the other team member with a car or plane.

Or maybe another team member would like to take some extra time and engage in some discovery and exploration along the way. Maybe they want to see if they can optimize or find better scenic routes or simply better-quality modes of travel altogether, resulting in a whole different approach that adds more value that no one would've discovered had she not taken the time to "smell the roses" along her journey.

But nevertheless, they all agree on the size of the distance, regardless of the time it takes or their style of travel. The two concepts are separate, and this is key to enable us to calculate total team velocity, and stay true to Agile.

Using hours instead of Story Points in estimation destroys the Agile culture in a team

Now that I briefly covered the technicalities of property measuring team velocity or speed, let's examine the devastating effects of using hours and time for estimation ignoring size and Story Points:

Shifted Focus from Product Value and Technical Discussions to "Faster and Cheaper"

Think "sweat shop". Time varies from one developer to another. Humans are bad at estimating in hours, not to mention that developers in particular have an inherent "optimism bias". Therefore, using hours will naturally focus the team on their "personal" time it takes to complete a story.

This in turn will raise negative competition among team members, focusing on finishing fast, not on doing things right. In the process, over time, this will increase the accumulation of more technical debt.

As you can see, this clearly undermines Agile principles. Estimating should be aligned with the Agile methodology, nurture it, and not work against it.

On the other hand, estimating in relative Story Points of the actual work, being focused on its complexity and volume, comes naturally to a Scrum Development team, as this is their domain of expertise. They will tend to do this more accurately, consistently.

Increased Stress Levels and Decreased autonomy

Team members differ in seniority, style of work, pace, familiarity with the product etc.. Therefore, this will lead to variation in time estimates. Imagine the impact of one team member who always estimates fast and another member needs more time. The negative impact will be devastating to the team productivity, morale, and long term value and TCO of the product.

The slower individual will definitely feel stressed, being pushed and not comfortable. He or she will feel a loss of autonomy because they either have to conform, forcing themselves to work on someone else's pace of work, or feel the pressure of compromising after arduous debates because one person's hour is not the same as another person's hour.

As for the faster team member, work will start skewing towards them, because they're just faster. They will also feel stressed and will be overworked and get burnt out.

Overall, the general symptom that will arise is that you will see high team turnover, and less work satisfaction, bad product quality due to the tech debt increased load, eventually, the product will collapse under its own weight when simple feature requests will be harder and harder to implement.

Inhibited personal growth

One major factor for a team member's satisfaction is learning and growing on the job. Teams around the world have been trying to implement this in various ways. For example, in some organizations, they allocate 10% or 20% of time for growth opportunities.

I have found that the best way to implement a new habit is to hook it into the existing flow of work instead of allocating it separately. Make it part of the current flow of work, part of the routine.

When team members are always in a fight or flight mode, in a deliver fast culture that is based on hour-based estimates, they don't have time to "smell the roses" along the way. No time to check out the latest technology on a story they're implementing. No time to pay attention to the architecture. Always in a rush to try to meet their timely forecasts.

As time goes by, this will eventually lead first and foremost to individual misery, and a knowledge-stagnant team that falls behind on the latest techniques, tools and technologies. Again, the product and business lose.

Having a work-oriented team vs. time-oriented team, using Story Points for estimating, works the time needed to do the job right (smelling the roses along the way) back to the discretion of the individual team members. Because now the team culture is not "Faster and Cheaper" but "Increase Product Value" which is the corner stone of Agile and Scrum.

In summary, using Story Points for estimations instead of only hours provides the following benefits:

A) Team conversations will center on value and technical subjects rather than competing on speed. In short, the team will be product-value oriented vs time-oriented.

B) Enable correct and accurate time estimates as the formula for velocity is now fixed. Makes management happier.

C) Forecasting myopia gets eliminated as now forecasts extend beyond the current Sprint after the team velocity is known.

D) Empowers team members with autonomy allowing for continuous learning and growth