Velocity estimation

Velocity is the rate at which work is Done. That's it, and it's only really of interest to the Scrum Team doing the work.

If management care about velocity, find out why. They should be more concerned about value delivered, and the systemic impediments to value delivery which they can help to remove.

@Ian is correct.  The velocity shouldn't matter to anyone outside of the team that is measuring it.  I won't get on my "how are you measuring velocity" soapbox right now but I'm happy to elaborate if you ask. 

The only thing that people outside of the immediate Scrum Team should care about is the continuous delivery of usable increments of value to the stakeholders. I am have seen teams that had great "velocity" but were terrible at actually delivering anything that the stakeholders found valuable.  One of those teams was one for which I was Scrum Master and we did it on purpose to illustrate the point to our executive management team.  It was a real eye opening experience for the entire organization.

Goodhart's Law: when a measure becomes a target, it ceases to be a good measure.

Thank you all for your reply.

 

@Ian, my management created a Center of Practice(CoP) for Scrum Masters. Leaders of CoP wants to implement  common method and practice of estimating velocity across all the Scrum teams in the organization. My challenge with this is

1. Team started showing  tendency to stick to the Planned Velocity instead of collaboratively deciding the stories/story points that they can  commit for the sprint (Goodhart's Law ?) 

2. If Velocity is the rate at which work is Done, then I assume the formula should be Velocity per team member per day x Sprint Capacity. But the given formula is Capacity percentage x Average velocity

@Daniel , It would be great if you can elaborate on  "how are you measuring velocity" 

Hi Praveen.

There is no "right" way to estimate velocity. But some ways are more wrong than others 😀

For example, I suspect the managers are searching for some degree of predictability. But it seems they are asking the team to measure how fast they can go in future. (Those are two different questions.)

Please have a look at this short article: https://scrum.works/articles/2019/06/Velocity-Escape-this-Pitfall/

I've tried to illustrate in that story that the fastest route is not the smartest route.

I suspect your managers will be happy if the 'velocity' metric appears to increase; but what if the team decided to go slower but on a more direct route? Their velocity may appear to decrease — would the managers get upset?

--

On a related topic, you might consider buying two books for your managers: #NoEstimates by Vasco Duarte; and Escape Velocity by Doc Norton.

@Daniel , It would be great if you can elaborate on  "how are you measuring velocity" 

Measuring velocity can be done in many ways.  Unfortunately, the most common is by counting story points that are "burned" during a Sprint.  I say unfortunately because in my opinion, that is the most flawed way of doing it.  So, the accuracy of the formulas will depend greatly on how accurate the data is that makes them up. 

If you calculate velocity based upon the number of completed or burned story points during a Sprint, you are measuring anything, in my opinion.  Story points are guesses made at a specific point in time based upon information known at that time.  As soon as work begins, new information is obtained and those original guesses are no longer applicable.  The guesses do not represent actual work being done so they do not represent any kind of movement, i.e. velocity. 

However, if you use metrics like throughput or cycle time to determine velocity, you are using data based upon actual work and can be used better to forecast future results.  These books by Daniel S. Vacanti could help you better understand how these metrics can be used.  

The use of velocity to predict future results is something that needs to be entered into with knowledge that each team will have their own velocity and that you can't compare one to the other with those metrics.  This is especially true if you are using something as abstract as estimate based data. But even if you look at throughput and cycle time, it still is only relevant to the individual team being measured.  This is because each team will decompose work differently, each team has different skills and work ethics.  There is no good way to compare teams when the work is creative like software development.  And anytime I see a list of metrics like you proposed, I can visualize the spreadsheets that will be used to generate graphs for the teams and individuals to determine if they are "performing". 

The same issue...

Any fresh ideas?