Companies That Obsess Over Velocity Are Clueless About Scrum
End the pointless velocity hysteria
Most companies using Scrum spend a lot of time discussing velocity and devising ways to increase it. Velocity becomes a magical, almost mythical number that developers must chase in every Sprint.
In companies where the velocity whip is cracked, comments like these dominate the conversation:
“Why was our velocity this Sprint lower than the last Sprint? Can you please provide a solid explanation?”
“Our velocity has stopped increasing. Maybe it’s time to hire a new Scrum Master? What’s the point in having a Scrum Master if they can’t increase our velocity?”
“We didn’t complete all stories in our Sprint. What can we do to guarantee we’ll complete them all next time?”
The race for an ever-higher velocity is the number-one reason why so many developers hate working with Scrum. There’s never enough time to catch your breath, to pause and reflect on your work.
As a result, the team becomes miserable and beaten-down. Programmers feel treated like assembly line workers who need to finish tickets as swiftly as possible. Slow down at any point and immediate punishment is to be expected.
Velocity worship is deemed necessary because developers are expensive and scarce resources — we need to squeeze every last drop out of them. Velocity is the perfect instrument to enforce this “biggest bang for the buck” thinking. A high velocity must mean we’re getting value for money out of our precious resources.
Unfortunately, nothing could be further from the truth.
Velocity — One Number to Rule Them All
As a result of the velocity hysteria, velocity becomes the one number to rule them all. Every Sprint, the numbers look great! But this numerical beauty comes at a hefty price — everybody on the team is miserable. The team realizes the only way to keep stakeholders happy is if their velocity obeys the laws of the universe: ever-expanding. And they know this isn’t something they are able to keep up indefinitely.
Companies brainwashed by velocity worship do not respect software craftsmanship, nor the delivery of value. All stakeholders care about is that one silly number, and when they can expect their feature to be live. Is technical debt slowing you down? Stop whining. That’s an imaginary friend who just prevents us from delivering more features. Stop talking about him. He’s overstayed his welcome.
Are developers assembly line workers? Do developers need a regular crack of the velocity whip to make sure they keep churning out features? Is delivering more features always better?
I believe the answer to all these questions is a resounding “No.”
Obsessing over the velocity of your Scrum Teams shows your company is clueless about the purpose of Scrum. Let’s go through all the reasons velocity worship makes no sense at all.
1. The Output is Less Important Than What the Output Achieves
The purpose of Scrum is to help you deliver products of the highest possible value. Measuring the developer’s output with velocity is easy, but that doesn’t make it matter. More features don’t mean more value or a better product. Allow me to illustrate with an everyday example.
I may spend eight hours writing an article which gets only 100 views. Sometimes I write an article in an hour on the train that gets over than 10K views. The relationship between effort and value is murky, at best.
Readers are clueless about how much time I spent working on an article. They only care about the value my writing delivers to them. The same goes for your customers — they couldn’t care less how much effort your developers have spent building a feature.
Stop optimizing for the amount of effort your development team spends. Start optimizing for the impact the feature makes on your customers. Delivering value is messy. Delivering value requires experimentation, trial and error, and room for reflection. By pushing your team to optimize the delivery of features, you kill the innovation and learning necessary to create a product that matters to your customers.
Does what your team produces results of value for your customers and the business? If they can do that by actually delivering less, that’s a win.
2. Velocity is Intentionally Excluded From Scrum
Velocity isn’t part of Scrum — it’s an optional and complementary practice. Velocity is something your Scrum team can decide to adopt or brush off. Your self-organizing Scrum team is free to stop doing planning poker and no longer report their velocity.
Velocity is seen as synonymous with Scrum. This is a fallacy. Scrum leaves it up to you to decide how you want to deal with estimation and throughput. There are countless viable options available to you: #NoEstimates, T-shirt sizing, Ideal Days, Capacity-Driven Sprint Planning, and many more.
If your velocity is dragging you down, please ditch it. Nobody but the Scrum Team decides how to estimate and forecast.
3. The Sprint Backlog is Nobody’s Business Except the Development Team’s
The Sprint is often seen as a way to oppress developers. It’s perceived as an instrument to pressure the team to complete as much work as possible. This line of thinking is flawed and false. Only the development team is allowed to make changes during the Sprint. Here’s how it’s phrased in the Scrum Guide:
Only the Development Team can change its Sprint Backlog during a Sprin— Scrum Guide, Nov 2017
‘During a Sprint’, okay. So when does a Sprint start and end?
A new Sprint starts immediately after the conclusion of the previous Sprint.- Scrum Guide, Nov 2017
As the Sprint is the container for all Scrum Events, your first Sprint starts at the first event: Sprint Planning. The second Sprint and any following Sprint starts when the time-box of the Sprint expires. Basically, you’re always in a Sprint.
In short: only the development team can change what’s in their Sprint, even during Sprint Planning. The view that the Sprint exists to put pressure on developers is unsubstantiated. Developers can only experience stress during the Sprint if the development team self-exerts that pressure. How much work is picked up, which ultimately produces the velocity, is solely at the discretion of the Development Team.
4. The Only Commitment Made Every Sprint is the Sprint Goal
Now imagine, even if the team adds too much work during the Sprint, they never commit to completing all work that was added in the Sprint Backlog. The development team commits to achieving only a single thing every Sprint: the Sprint Goal.
What does this mean for your development team? As long as the Development Team doesn’t put the Sprint Goal at risk, the Sprint Backlog is completely flexible. Sprint Backlog Items that do not relate to the Sprint Goal may be carried over to the next Sprint, at no penalty. The plan and the work necessary to meet the Sprint Goal can be discussed and amended at any time.
Meeting the objective is more important than following the plan, or completing a specific body of work. There is no commitment on velocity, only a commitment to a goal with variable scope.
5. Scrum Already Creates Enough Urgency to Deliver
Scrum already contains enough devices that put a healthy pressure on your development team to deliver a working product every Sprint. The Sprint, Sprint Planning, Daily Scrum, and the Sprint Review all serve this purpose. Heck, even the Sprint Retrospective is for learning what you can do better so you can deliver a Product Increment next time.
The presence of these events, make putting additional pressure with velocity unnecessary and even harmful. Each working day urgency is instilled to meet the Sprint Goal at the Daily Scrum. To do Scrum well requires discipline and focus. Putting too much velocity pressure on your team just buries your team and sets them up for failure.
Companies Should Show More Trust and Respect To Their Developers
A velocity obsession is a tell-tale sign of the Feature Factory mindset. Caring about velocity indicates the company believes delivering more features is always better.
Unfortunately, more features doesn’t mean more value is delivered. To deliver value, you need the time to experiment, innovate and reflect. By putting too much pressure on building, you remove the breathing space necessary for creativity and figuring out what really will make a difference.
Not obsessing over velocity is a matter of respect: Do we believe our developers are capable and trust them to deliver without a velocity sword poised to strike them? Scrum already contains enough instruments that instill a sense of urgency to deliver something valuable every Sprint.
Scrum gives developers far more power than most people believe. Don’t allow a self-serving and erroneous interpretation of Scrum to put you in an imaginary box. Break free of this box and use Scrum to your advantage. Don’t be fooled by the velocity nonsense your company is feeding you. Scrum gives a lot of power to developers — by design. Don’t take my word for it, read the Scrum Guide on your own.
Scrum, by design, wants to empower the people that do the work to invent their own rules. Use that power to work at a sustainable pace and work on technical debt as you see fit. If you’re working as a cook in a restaurant, you don’t need to ask permission to clean the kitchen while you are cooking. Why should developers ask for permission to clean up their code? If it’s necessary to do your job, you shouldn’t need to ask anyone for permission.
As long as you can deliver the Sprint Goal as promised, nobody should be bothered by the other things you do in the shadows to make the product deliver value to your customers and the business. No one should even care about how many Backlog Items you complete, as long as you deliver a product increment that meets the Sprint Goal.
Developers — don’t allow yourself to be bullied by velocity. Put yourself back in the driving seat where you belong. Don’t let others, who have no clue what you’re doing, dictate how much work you pick up. You know best — as a professional you deserve this respect and trust from the company you work for.