Skip to main content

Velocity estimation

Last post 07:11 pm February 1, 2024 by Martin Stas
7 replies
05:34 am October 8, 2023

My scrum team follows two week sprints cadence . During Sprint planning, team takes the average velocity of last 6 sprints as a guideline  and based on team's confidence level they commit stories for the sprint  after factoring in holidays and PTOs. But recently our management asked us to estimate and report  upcoming sprint velocity. Management shared an excel template for this which has the below formula

 

Full Capacity = Sprint length x Number of team members 

Sprint Capacity = Full Capacity less holidays and PTOs

Average Velocity =  Average Velocity of last 6 sprints

Capacity percentage = Sprint Capacity/Full Capacity

Planned velocity = Capacity percentage x Average velocity

 

Is this the right way to estimate velocity?

 

Thanks


07:53 pm October 9, 2023

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.


08:44 pm October 9, 2023

@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.


11:48 pm October 9, 2023

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


07:27 am October 10, 2023

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" 


08:53 pm October 12, 2023

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.


03:37 pm October 13, 2023

@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". 


06:28 am February 1, 2024

The same issue...

Any fresh ideas? 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.