Velocity is one of those “things” that is often:

  • Misused

  • Misunderstood

Most of the time, the first question about velocity is:

Does it measure effort?

Velocity does not measure effort: the effort that stable Teams expend during a Sprint is constant because the Sprint duration is constant.

So… what is Velocity?

Velocity represents the total amount of work Done, by the Definiton of Done, during a Sprint.

It is a sum of the estimates for the Product Backlog Items (PBIs) included in the Sprint. Each estimate forecasts how much work it will take to complete a given PBI relative to the amount of work for other PBIs. Think Story Points.

Is Velocity variable?

Velocity varies from Sprint to Sprint due to many factors:

  • Team member(s) not available for whatver reason

  • Equipment problems

  • Quality of Requirements

  • Unknowns and other factors

How do we determine Velocity?

In most cases, the number of points completed in the last Sprint is a good predictor of how many points of work the team will complete in the next Sprint.

Teams can use velocity as a forecast of the work it will complete, but it is not a target or a guarantee for stakeholders.

If the weather forecast for tomorrow is sunny and dry, that is not a guarantee but only an informed guess.

How much is too variable?

If velocity is wildly variable, you will never be able to plan with any confidence. Yes, I am aware that plans are subject to change but if you can’t start on ground that is constantly shaking… A Product Owner needs a certain level of predictability to be able to plan.

That also affects process improvement. If it gets wildly variable, the team can’t measure whether anm experiment worked or failed.

Can we talk more about variance?

Always remember that the Scrum Team commits to the Sprint Goal and not their forecast velocity.

To reduce variance and eventually increase velocity, teams must be:

  • Cross-functional

  • Free of micro management

  • Have good requirements

Scrum Masters can help with the first two and Product Owners with the third one.

I always recommend that you share value metrics such as return on investment (ROI) data with your team because velocity alone does not indicate value. Velocity is a tool for prediction and that value is the goal.

Velocity has a mean and a variance, and both are important to forecasting. A velocity with low variance leads to more precise forecasts and makes it possible to assess whether a kaizen improved the team’s process and therefore performance.

Team’s velocity is a reasonable forecast of performance based on an average of the team’s recent velocities. Many teams use a moving average data from 3 to 5 most recent Sprints.

Other teams keep a cumulative average of the velocity of all Sprints. Compared to a moving average, it diminishes the impact of recent performance. Because teams should get better over time, it is better to measure recent velocity so a moving average is more accurate.

One downside to using a moving average is that a really good or really bad Sprint has some impact on the velocity for the next several Sprints, so you may consider ignoring those cases.

Recent Posts

See All

Prior to the Scrum Guide 2020, the backlog refinement used to be regarded as a “quasi event” and a lot more was mentioned about it. So, what happened? As we know the Scrum Guide 2020 was “leaned” and

The Scrum Guide states that the Scrum Master is accountable for the Scrum Team’s effectiveness. Improvement is key to effectiveness. Previously, we discussed Scrumming the Scrum. That was all about co