Knowing how much work your team can do within a sprint is essential to making predictions for planning activities. Planning and release forecasting are very much valued by the business and engineering teams. Story point estimation and velocity are great ways to enable both.
Still, some people ditch velocity because they perceive it as a distraction instead of help. Putting features live faster for a smaller audience and learning from them is more valuable than pursuing vanity metrics.
You may still opt to use velocity. But first of all, you have to ask these questions:
Do you know why others use it?
How does that contribute to creating more value sooner?
Let's examine some common cases:
1. If you ask me, "can we use velocity to evaluate individual performance?" my answer would be "No." It is a team metric. You can use it to see the growth trends and predictability %.
If you observe issues stabilizing the velocity, start with something other than tracking individual ones.
The root cause might need you to take action on other aspects of the teamwork. Deep dive into the work process, and you might inspect some strange behaviors unrelated to the velocity itself.
2. If you use velocity to compare teams' performance, then you're on the wrong path.
Team A might be pushing 30 story points per sprint, and team B might be pushing 20 story points per sprint.
Which team is better?
That is the wrong question to ask and the wrong attitude to show.
Instead, look at one team's progress compared to the last sprint, last month, or last goal. It will tell you much more about the quality of work than the static numbers you get.
3. If you use velocity to measure productivity (output and not outcomes), you will get "gamed" numbers. The most important is getting results, not velocity; many teams don't realize that.
The obsession with velocity causes teams to quickly develop many features instead of optimizing the flow to become more agile.
Velocity never was supposed to be a performance metric that people were supposed to increase. That's why it's a problem.
4. Using a Focus Factor to minimize deviation from planned work and to estimate the Dev team and QA team capacity and velocity separately will make the team focus on vanity metrics more. This should have been done by Lean metrics.
Things to remember:
- More story points do not create more value.
- More live features cannot guarantee to improve your customers' lives.
- Diagnosing dysfunctions like what's going on behind the decreased velocity can identify problem areas unrelated to the velocity.
- Focus more on the capacity to stabilize the velocity and not overload the team.
Velocity is supposed to aid planning, nothing more, nothing less.
When your energy goes to vanity metrics, you get meaningless results.
It's okay to be fast, but it's much better to be agile.
Hope you find it helpful. :)