Running Average Velocity
... a team has established its initial velocity. As the release progresses, the velocity changes due to numerous different factors. It is essential to update the velocity to keep the project running accurate.
✥ ✥ ✥
You want the velocity to reflect the team’s current abilities, but it takes time to know whether process improvements actually worked.
In most cases, a team’s velocity mirrors its past performance (see Yesterday’s Weather). A deviation from the current performance may be an anomaly caused by some unique event. In such cases, the velocity will probably return to its previous level.
On the other hand, there is no such thing as a "stable velocity." Every sprint is a little bit different: people may act differently, and especially the work changes. (If it were exactly the same from sprint to sprint, we would call it "manufacturing.") Stability comes from false counting. Therefore, while Yesterday’s Weather is a good way to establish an initial velocity. it should not become a habit. Teams that do that really have no evidence-based control of their processes.
Even if the team made intentional process improvements, it isn’t immediately clear whether the velocity improvement was caused by the process improvement. It could be a coincidence, or due to some other factor (reference “The Hawthorne Effect”.) So one must not increase the expected velocity just yet.
On the other hand, the process improvement may well have caused the velocity to increase.If this is the case, it would be more accurate to increase the expected velocity.
Likewise, a dip in velocity may be because of a one-time event, in which case it might be ignored. But a different one-time event might happen in the next sprint, so ignoring it might be an exercise in self-deception. 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 a serendipitous 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, one should use at least three sprints. Projects will often run three initial sprints to establish the team's velocity.
One might also use more than three sprints for the moving average. A larger number decreases the impact of a single anomalous velocity. However, note the following about including many sprints.
An alternative approach is to simply keep an average of the velocity of all sprints, and not bother with a moving average. This is also a useful practice. However, compared to a moving average, it dilutes the impact of recent performance, and retains the influence of old velocities which 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.
When a one-time bad event happens, there is a temptation to make an exception for it; to omit it from the moving average. While you might make an excuse for it, this can be a dangerous practice, as it can become a habit to ignore bad news. More fundamentally, one-time events are a part of life: one-time events come along pretty regularly! Intentionally discounting them is ignoring reality.
Any calculation of velocity must be predicated on fact. This means that the team has a rigorous Definition of Done. Furthermore, the team must adhere to the definition (see DoneMaster for help.) These must be established before you can talk about velocity in any meaningful way. First things first.
Velocity is also closely tied to estimation. Inaccurate velocities are products of poor estimation. Over time, teams get better at estimating, so later velocities should also become more accurate. A moving average accommodates the increasing accuracy.
Some teams may use a range of velocities rather than a single velocity for their 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.
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.
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 an alternative approach to “Updated Velocity”