Running Average Velocity

... a team has established its initial velocity. As the Sprints progress, the velocity changes. It is essential to maintain a reliable Sprint forecast.

✥       ✥       ✥ 

You want the velocity to reflect the team’s current capacity, but it takes time for the velocity to stabilize after a change.

In most cases, a team’s velocity mirrors its past performance (see Yesterday’s Weather). One time situations may cause a surprisingly large change in velocity. The velocity will probably return to its previous level in the next Sprint.

On the other hand, there is no such thing as a “stable velocity.” There is natural variance in the work, in people’s behavior, and in the requirements for any complex development. If the velocity were the same from Sprint to Sprint then, we would call it predictable manufacturing. Yesterday’s Weather is a good way to get started.

If the team implemented a process change and the velocity went up, it isn’t immediately clear whether the velocity increase was caused by the process change. It could be a coincidence. [1] So it would be premature to adjust the expected capacity.

On the other hand, the process change may well have caused the velocity to increase. If this is the case, it would be more accurate to increase the expected capacity. Likewise, a dip in velocity may be a one-time event, in which case you might be tempted to ignore it. But a different one-time event might happen more often, so ignoring these might be fooling yourself. Yet we must not get overly excited about possible catastrophes.

Velocity is a motivating factor for teams — they like to see velocity increase. This can lead to unhealthy behavior: people might overreact when faced with sudden changes in velocity. For example, a sudden drop may provoke panic and emergency measures, while an incidental increase may become the next Sprint’s “required” velocity.

In summary, while an accurate picture of the team’s velocity is a crucial metric for both accuracy and for improvement, many things conspire against it.


Use a running average of the most recent Sprints to calculate the velocity of the next Sprint.

To get a meaningful running average ([2], [3]), one should use at least three Sprints. Teams will often run three initial Sprints to establish the team’s velocity. Velocity is empirical, you can measure it but not assuredly predict it.

One might also use more than three sprints for the moving average. A larger number decreases the impact of a single anomalous velocity.

The best teams use a range of velocities [4] rather than a single velocity for their release planning. How velocity is used is actually outside the scope of this pattern, which focus on the calculation of the velocity figure. But one can easily use a running average for velocity ranges.

When the composition of the team changes, its velocity is perturbed. You could reset the moving average at this time. However, even if you don’t, the moving average will correct itself over a few Sprints.

✥       ✥       ✥ 

A good velocity in hand, the Development Team properly can size the Sprint Backlog, and can roughly forecast the content of the next few Sprints.

Velocity measures how much is done within a Sprint, therefore the team needs a Definition of Done.

Velocity is closely tied to estimation and using a running average increases the reliability of your estimations.

The effect is that any deviation in velocity, either improvement or deterioration, has some impact on the velocity. This can encourage teams to improve velocity and to avoid things that negatively impact velocity.

An alternative approach is simply to keep an average of the velocity of all Sprints, and not bother with a moving average. Compared to a moving average, it dilutes the impact of recent performance, and retains the influence of old velocities from Sprints that may have followed different practices. Because teams should get better over time, you want velocity to be weighted in favor of more recent activity. Therefore, a moving average is more accurate than a non-moving average.

One downside to using a moving average is that an anomalous Sprint has some impact on the velocity for the next several Sprints. If its impact is large, it creates a one-time artificial opposite effect on the velocity when it leaves the moving window.

Note that a running average velocity must be coupled with a culture of sustainable improvement. There is natural pressure from managers and from the team itself to continually improve. Too much pressure can burn out the team, and impel them work long hours and even fake the numbers. When either of these happen, the velocity numbers are compromised.

This pattern is related to Updated Velocity. This pattern describes the calculation of velocity to smooth out anomalies. Updated Velocity describes when to raise the bar.

[1] Henry A Landsberger. Hawthorne Revisited. Ithaca: Cornell University Press, 1958.

[2] Mike Cohn. Agile Estimating and Planning, 1st Edition. Englewood Cliffs, NJ: Prentice Hall, 2005.

[3] Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Reading, MA: Addison-Wesley Signature Series (Cohn), Aug. 5, 2012.

[4] Mike Cohn. Succeeding With Agile. Reading, MA: Addison-Wesley, 2009.

Picture from: