Raise your hand if you’ve ever had a manager obsessed with your team’s velocity. Yeah, that’s what I thought. Velocity is the go-to metric for tracking agile teams in many organizations. But is it really telling the whole story? From where I’m sitting, overemphasizing velocity can cause some severe problems.
As a CTO, I understand the need for a metric to drive the process. But velocity as the be-all-end-all solution doesn’t cut it as it doesn’t capture real productivity for many reasons. We should take a more balanced and empathetic approach to managing agile teams.
Are you guys slacking off?
This happened ten years ago when I worked as a senior engineer for a startup. I was beyond frustrated. I worked nights and weekends to build a key feature for them for a few months. But after the sprint demo, the client, Jason, pushed me again on the call about velocity being too low. We were using Pivotal Tracker at the time, which tracked velocity automatically using the story points estimations by developers.
“I don’t get it,” Jason said, shaking his head. “Your velocity dropped by 50% this sprint even though we didn’t change anything. Are you guys slacking off?”
I was doing my best, distracting myself and holding back a fiery response. My exhaustion was mirrored in the faces of other devs on the call.
Our team had been heads-down, solving a major architectural challenge left unaddressed for too long to a point where it became a blocker while also dealing with contradictory search requirements that Jason constantly changed. But, he only saw the steady decline of velocity metric and a lack of new user-facing features for quite a while.
“No, we’ve just been focused on some major tech debt this sprint, plus you keep changing the requirements, “I said calmly. “But the tech debt work should pay off soon in performance gains.”
Jason crossed his arms. “That may be true, but we can’t have velocity tanking all the time. I’m going to need your team to pick up the pace.”
I left the room fuming, knowing that we were expected to spend ruthless nights and weekends crunching out buggy code, all to superficially boost our story point count. There had to be a better way.
Stop Obsessing Over Velocity
Let’s be honest — when management is laser-focused on increasing the pace every single sprint, it puts the team in a tough spot. Take my story, for example. My manager Jason was relentless about velocity goals at our standups, without caring that the team was deep in the weeds on some complex tech debt issues.
You can guess what happened next. The team was forced to rush out half-baked code to pump up the story points and please Jason. Not cool. This is exactly how obsessing over velocity backfires. Please need breathing room to focus on quality and long-term sustainability, not just chase arbitrary targets.
Managers would get way more understanding from digging into what’s blocking teams from delivering rather than waving around velocity reports. Support developers by clearing roadblocks, not cracking the whip.
Velocity Doesn’t Equal Productivity
We knew we’d have to game the system by splitting every user story into ten tiny tasks to hit Jason’s new velocity goals. It’s like with estimates — if you apply too much pressure, developers will multiply every estimate by 3x. Sure, the points per sprint skyrocketed, but were we any more productive? Nope. We were creating busywork to juice their metrics. I’m not proud of it, but this happens more often than it should.
If you really want to measure productivity, look at things like cycle time. How long does it take from starting a feature to deploying it? That’ll show if a team is moving or starts to tread water. Going crazy over story points motivates the wrong behaviors.
Transparency Beats Metrics
When you only look at velocity as the magic productivity number, it makes developers feel like management doesn’t get or care about their actual day-to-day work. I would love for Jason to participate in our technical standups and planning meetings instead of fixating on velocity alone. But they were too detailed and technical for him.
Being involved in the dev process builds empathy and trust between teams and leadership. You start to see why certain sprints take longer or where teams are getting stuck. Way more value than any metric can give you.
Velocity Makes Every Sprint Seem Equal
Besides, let’s keep in mind that we’re dealing with high uncertainty as engineers. Every sprint is different. If my team knocks out a huge new feature one sprint and then pays off tech debt the next, our velocity will be different. Pretending every sprint is equal doesn’t make sense.
Savvy managers set expectations by looking at the goal for each sprint instead of solely relying on the past. My manager, Jason, needed to understand why that tech debt sprint was heavier than the regular one. With good communication about sprint objectives, velocity fluctuations won’t catch anyone by surprise.
It’s Time to Move Past Velocity Obsession
More than anything, stop treating velocity as the holy grail for measuring teams if you’re still doing so. Sure, it gives some interesting data points. But obsessing over it backfires.
Instead, focus on understanding what’s actually happening with your team day-to-day. Get insights into blockers, changing priorities, and lighter sprints versus heavy lifts. Be flexible and set reasonable expectations.
And remember about quality! Pushing teams to deliver at breakneck speeds sounds good in theory. But without thoughtful design and testing, you’ll end up with a buggy mess. Let’s build things right, not just fast, for the sake of story points.
Originally published on Meidum.com
