Why teams should stop obsessing over their velocity
Just because something is easy to measure doesn’t mean it’s important. — Seth Godin
When I started working with Scrum six years ago as a development team member, I entered the realm of Story Points and velocity.
I loved it.
Every Sprint you have a clear number that shows how your team performed. At the Sprint Review, stakeholders would be jubilant when our velocity was high. The Scrum team would be proud at the Retrospective as well.
When our velocity was low, the opposite was the case. The stakeholders at the Sprint Review would be unhappy. During the Retrospective the whole team would be sad and reflect on what to do better next time.
In novice Scrum Teams there is often a clear relationship between velocity and team happiness.
But does a high velocity really matter? Should we really care so much about having a stable velocity?
I am a Product Owner and I have noticed that over the years I actually care less and less about my team’s velocity. I also try to teach my teams that velocity is a poor measure of the value we delivered.
Sounds strange? Allow me to explain.
What is velocity actually good for?
Velocity is a tool for Scrum Teams to help with planning the Sprint. A team’s velocity represents the amount of Story Points completed during a Sprint. It can be used to plan future Sprints. It is simple to use and easy to measure. Velocity helps the development team to not take on too much work in a Sprint. Taking on too much work results in everybody being busy, but nothing being completed during the Sprint.
Product Owners may use velocity to forecast timelines to stakeholders about when they expect a bigger feature or project to be completed. Velocity is useful for forecasting timelines, but without a significant scheduling buffer you’re setting yourself up for trouble. Even if the team velocity is super stable.
There is simply more unknown than known before you actually start working on something. And this is where most uncertainty in timelines actually comes from, not the stability of the velocity. This is where the empiricism of Scrum shines and helps to make decisions based on what is known.
Novice Scrum Teams and Scrum Masters, usually treat velocity as the holy grail of team performance. Even if they do not want to, the management usually loves velocity and they make it matter to the teams too.
Is this justified? We can answer this by asking a follow-up question:
What is the relationship between effort and value?
That’s right, there is none. So a higher velocity, does not mean you are delivering more value.
As a Product Owner I care about the delivery of value, not so much about the delivery of features. Velocity and features are a means to an end and not a goal by itself.
Obsessive focus on velocity is a symptom of the feature factory mindset
By celebrating a high velocity we are putting the team in a feature factory mindset. Shipping more features is better. I do not believe in this way of working. We should celebrate outcomes instead of output.
In the words of famous designer Dieter Rams who inspired Apple and Steve Jobs:
“Less but better” — Dieter Rams
I’d rather do less, but more of the right thing. You appear to be moving slower, but you are actually moving faster.
Imagine you own a book publishing company. You are approached by two writers: author A who wrote a book of 123 pages and author B who wrote a book of 621 pages. Which one would you publish?
It is hard to make a decision just on the number of pages right?
The book of 123 pages is ‘The Stranger’ by Camus, which is world-famous and a critical success. The 621 pages book is a random book that would turn out to be a dud.
Book publishers do not judge their writers on the amount of pages they write. For Scrum Teams it should not be any different. The team should not just be judged on their velocity: how many product backlog items they complete.
So what should Scrum Teams care about?
A Scrum Team should celebrate outcomes over their output. How can a team achieve this?
By focusing on the few things that really matter and try to nail them:
“The Essentialist deliberately distinguishes the vital few from the trivial many, eliminates the nonessentials, and then removes obstacles so the essential things have clear, smooth passage.” — Greg McKeown
Every Sprint the team commits to a clear outcome: the Sprint Goal. The whole team should understand why the Sprint Goal matters and what the value is we are expected to deliver.
A clear Sprint Goal shifts the responsibility of the team from the output (scope) to the outcome. If we can reach the same goal by delivering less scope, great! That’s a win in my book.
When the Scrum Team commits to a Sprint Goal there are only four things that really matter after finishing a Sprint:
- Did we meet the Sprint Goal?
- If we did not meet the Sprint Goal, what can we learn from it so we can do it better next time?
- If we met the Sprint Goal, did we deliver the expected value?
- If we met the Sprint Goal but did not deliver the expected value, what can we learn from it?
Stop obsessing over your velocity, start obsessing over your outcomes
Velocity might still be useful to troubleshoot a team and figure out what is going wrong. But it should not be front and center to decide how a team is performing. There is no relationship between effort and value.
By celebrating velocity you put teams in a feature factory mindset where delivering more features is better. It is better to do less, but more of the right thing. You will appear to be moving slower, but you are actually moving faster.
By using Sprint Goals we can shift the focus from the output (scope) to the outcome. If we can reach the same outcome with less scope, then that’s a great thing! A clear Sprint Goal also provides the team with flexibility as more is learned.
Instead of obsessing on the delivery of features, we should obsess on the delivery of outcomes. This is much harder to do, but in the end the only thing that really matters. If a feature does not deliver a valuable outcome to the customer, then who cares if our velocity was great?
