Velocity Is Not the Goal
"ve·loc·i·ty (n) - a measure of how many points a team completes during a sprint."
On velocity
Velocity is often the first scrum metric we encounter. It's a quick way to gauge how many points a team completed during the previous sprint, and how many they'll likely complete in the next. It's clean, simple, and easy to understand. It's also easy for people to get attached to.
On predictability
Teams that post consistently high velocities are often treated as valuable to the organization. However, those teams that tend to be more erratic...posting a high velocity one sprint then falling off dramatically the next...may not be as valuable as they may first appear.
The reason is that velocity isn't as valuable as predictability. Much of what we do in agile is done with the aim increasing the predictability of our team. The more predictable a team is, the more effectively we can plan into the future. This lets us take risks more intelligently as well as formulate more realistic strategies based on what our teams can likely deliver in a given timeframe.
Teams that post high velocities followed by low velocities are very erratic, and thus can't be planned for. And if a team can't be planned for, then its value to the organization declines.
What's the harm in an erratic velocity?
Erratic velocities can lead to difficult planning for any team. Not only long term release planning, but even short term sprint planning will suffer since the team won't be able to accurately forecast how many points they can complete during a given iteration.
If your team is experiencing erratic velocity, then it may be time to look upstream at your estimating process. Often unpredictable velocities or missed forecasts are the result of poor estimates at sprint planning time. Even exceeding your forecast can be a symptom of over-estimating the amount of work selected for the sprint.
Regardless of whether your estimates are missing up or down, your planning process is suffering.
So what's the goal?
If velocity isn't the goal, then what is?
Regardless of the hype surrounding 'fast' agile teams, at the end of the day agile is often more concerned with predictability than speed. Posting a high velocity for one sprint isn't helpful if your team can't sustain it. However, posting consistent velocity numbers goes a long way towards great planning.
Does this mean that a team shouldn't strive to produce their velocity? Not at all, it means that improving a team's velocity shouldn't be its goal. Instead, the team should focus on what it takes to improve that velocity. Practices such as continuously improving the engineering process or systematically identifying and chasing out risk will naturally result in higher velocity.
Focus on these things and the velocity will come.