Skip to main content

Is Sprint Velocity meaningful?

Last post 02:10 am April 6, 2023 by Rod Spears
5 replies
03:44 pm April 5, 2023

I heard this from an engineer:

Measuring and comparing Sprint Velocity is like timing individual car trips from New York to Los Angeles. The driver can never take the same route twice, but must always increase their speed.

03:57 pm April 5, 2023

Velocity can be one useful input and empirical piece of data to assist a team with forecasting how much work can be completed, so some Scrum teams find it useful for Sprint Planning. Release forecasts could also be derived using velocity. 

The goal of velocity is not to be increased each Sprint. That just results in bad things happening, such as cutting corners.

Scrum is lightweight, intentionally incomplete, and doesn't mandate the use of velocity. In fact, it isn't even mentioned in the Scrum Guide. Some teams choose predictive forecasting methods, which include throughput, scatter plot probabilities, and monte carlo forecasting.

The analogy doesn't resonate with me, to be honest. Comparing complex work compared to taking a trip is much different.

Scrum on!

04:06 pm April 5, 2023

It can be meaningful to those doing the work driving, and who are accountable for the quality of what they are doing, including the safety of those around them.

Passengers who demand "faster, faster!" are not accountable, but they nevertheless pay a heavy price for calamity, and so are wise to let the driver choose a safe velocity for them. The speed they crave will indeed prove meaningless, when upon arrival nothing is done or delivered, assuming they arrive anywhere at all.

05:20 pm April 5, 2023


I think the point of the analogy is that there are endless random paths to get from point A to point B. There isn't anyway to ensure that any next random path will be faster than a previous one. The number tickets in a Sprint are random, Story Points are random estimates, the backend going down during development is random. Developer's skill and domain knowledge is essentially random. If that is the interpretation of the analogy, then I don't see how management can insist on Velocity to be ever increasing. Not mention taken to its logical conclusion, eventually Velocity will be infinity.

I also agree with Ian, that faster isn't better. Plus, engineering "could" always game the system when estimating Story Points. I have always felt that management wants software development to behave like and be as predictable as, a factory assembly line. It just isn't going to happen.

09:12 pm April 5, 2023

In my experience a lot of the validity depends on what you are using to measure Velocity.  If you are using Story Points, my believe is that is a useless endeavor.  As you said, Story Points could be random.  They are an estimate (also known as a guess) made at a specific point in time based upon the information you had available.  As soon as new information is gained, that original guess is no longer valid. 

However, as @Chris points out, if you are using some other metric to determine "velocity" it can be useful.  For example, cycle time or throughput have always been good choices for my teams.  They are based upon the actual time expended and are more accurate than depending on guesses.  However, velocity is only useful for the team that is responsible for the work.  And every team will be different.  Velocity can be useful for determining if a selected body of work can be completed during a specified duration of time.  But that is all it is useful for and it is not a certainty.  To use the travel analogy, even if you use the same path every time, the times to complete the travel could vary because of weather, road conditions, other drivers on the road, and even the need to stop for fuel or biologic breaks. But you can have a fairly good idea of the time it will take if you make the trip enough times and do the math.

@Ian has a great point.  Constantly trying to increase speed is going to lead to problems.  There is nothing in any of the agile practices that I know where the goal is to constantly be faster.  In all of them that I have ever encountered, being consistent is more important than being faster each time.  You want to reach a sustainable pace of delivering value.  That leads to better predictability, less burn out, consistent code quality.  It is much safer and a better option for any organization.

02:10 am April 6, 2023

Thank you for your thoughts Daniel, I agree.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.