Velocity has become a word specifically associated with measuring how well a Scrum team is doing. This metric is often associated with negative feeling new Scrum Teams are feeling towards Agile in general. However, the issue with velocity is not the metric itself, but rather how we use it. In this video, I will be sharing how to use and how NOT to use velocity with a few examples and metaphors.
Velocity and performance
I often encounter Scrum teams that have a very adverse reaction to velocity and don’t want to even track in. Teams (and Scrum Masters alike) are worried about the points on stories that they couldn’t finish. How do you split unfinished user stories so that the team doesn’t lose points in the Sprint? They did the work ofter all.
And here is where we see the biggest problem, because velocity is used as a performance metric.
The team knows that stakeholders will be judging them based on that number. Is it consistent? Is in increasing? It has to increase, right?
Wrong!
Velocity does not represent performance of the team, nor does it represent the value delivered. It just represents an average amount of work a Scrum Team usually completes within a Sprint.
It’s important to note the two words in this last phrase: “average” and “usually”. What they represent is uncertainty.
Remember that velocity is based on the estimated effort and complexity of work before that work actually started. And since product development lies in a complex domain, this estimate is by default most likely is incorrect.
What does it all mean? We need to go back to why Agile even came around and what relative estimation really is. Unfortunately, this blog post is not about agility in general. If you want to learn more about the topic and truly understand Agile, I recommend checking out my online course “Success with Agile and Scrum”. It’s a perfect place to learn key aspects of agility and actually implement them in your real work.
Learn how to use velocity the right way (and teach your team too!)
With this workshop facilitation guide, you’ll be able to practice Agile estimation like Planning Poker together with your team and use it to forecast delivery.
Velocity in planning
Ok, I clearly stated that velocity is not good for measuring performance or value. “Then it must be just a useless metric created to pressure the teams to deliver faster?”
Actually, velocity is a very useful and practical metric that can bring a lot of value to Scrum teams when used correctly. It can help teams identify areas of improvement and become more successful with Agile.
The correct use of velocity is “for the team by the team”. It’s an internal metric that a Scrum team can use to plan their Sprints and their Product Backlog.
Since it’s an average of how much work a team usually completes within a Sprint, then it can help how much work to take into the next Sprint (approximately).
It’s a great way to plan based on data you have collected in the past Sprints. It removes the guesswork from Sprint Planning and allows the team to focus on the WHAT rather than HOW MUCH.
And when I say “internal metric” it means that it is used by the team only. It’s not something that needs to be presented externally as for anyone outside of the team this number won’t mean anything.
A good way to use this externally, is when you plan for specific scope or for a specific deadline. This is where the Product Owner would be able to look at the Product Backlog and based on average velocity forecast how much scope might be completed by a certain date or how much time a team might need to deliver a certain amount of scope.
There are many important metrics that can help you measure the success of Scrum and help your team find opportunities for improvement. Head over to the Agile Metrics section in my blog to learn more about it.
As always, a question to you for some self-reflection:
How do YOU use velocity? Does it bring the value it should? And if not, what should you change in collecting or tracking velocity to use it properly?
