Obviously I am very opinionated on the topics I choose to write about. And I voice my opinions based on experiences both of my own and shared with others. Obviously, the title of this one should leave nobody guessing my stance on Velocity. Can we just get rid of this metric already?
The different levels of dysfunction that comes with Velocity is staggering. So where do we start?.
Culture of Velocity
How would one describe a culture that supports the velocity metric?
“A psychologically unsafe place where people consistently lie to one another about numbers for the sake of reporting, providing management with data to drive people on how much they need to improve.”
Increasing the Teams Velocity
Velocity is not the performance or efficiency of a team. It is the average number of items a team turns into increments of software over a given period of time. Velocity should be something only used by the team as a sanity check to ensure they aren’t over committing or it can be used for long-term forecasting.
But I would suggest anyone who thinks velocity is the only way to provide long-term forecasting to please purchase “When Will It Be Done?” by Daniel Vacanti.
Setting Team Goals Based on Velocity
That’s right. Teams have actually set goals to reach a certain Velocity number. Why would teams do this you ask? Because management has decreed that the teams velocity must improve. So naturally, since the team now has a metric they know they will be judged on, it is now a point of focus to improve said metric. But what does that look like when a team does this?
Typically what happens is the gaming of the velocity metric. This is either done by:
- Creating an Story for the API
- Creating a Story for the Database update
- Creating a Story for the UI
- Creating a Story for the Documentation
- Creating a Story for the release of an Increment
- etc…
Bottom line, teams define the scope of work. Therefor teams can easily decide what the numbers look like.
Maximum Velocity
Teams focused on Velocity often use it for planning. When they do this, they often plan to maximum, or very close to maximum velocity. This leaves little to no time for slack. This is especially true when management gets their hands on this metric. Teams need slack time since this isn’t trinkets we are building here.
Recently worked with a team that experienced this first hand. Simple Story, well we all thought it was a simple Story, was added during the Sprint Planning. This Story was right-sized down to a single acceptance test. Everyone was extremely confident this could be done in 1-2 days at most. This Story though, caused some unexpected issues, both in functionality and implementation and ended up taking most of the Sprint to complete. Planning for maximum velocity would not have allowed them to have the slack time needed to dig into this Story and resolve the issues that were being experienced.
Critical Things Not Considered W/ Velocity
Often when Velocity is the only thing used for planning out an iteration, teams will look at only the new Stories. And thinking of these Stories in ideal scenarios. Thus leaving out the thoughts of:
- Technical Debt
- Defects and Bugs that arise
- Building out proper testing
This causes quality to suffer.
Comparison
Another management issue here as Velocity has, and will be used to compare teams. No two teams can, nor should be exactly the same. People are different and teams experience a slew of different issues while working.
When management uses Velocity to compare teams, they are missing the nuances of people and thinking of them solely as machines turning out code. People have lives, and shit happens.
False Promise of Delivery
Velocity is based on estimates traditionally. And estimates are fraught with problems. Mainly that no matter who you are or what the work item is, an estimate is a guess. But it is treated as a guarantee and therefor, so is the Velocity.
If you use Velocity as a guarantee of what will be done in a given time-frame, you are setting yourself up with unachievable expectations.
Individual Velocity
Excuse me, but what the hell is wrong with you? Organizations will do this, and you should run fast and far away from such organizations. This is done when their are individual performance goals tied to this metric.
The behavior from this is extremely dysfunctional. There is absolutely, in my opinion, no value to tracking Individual Velocity.
Velocity != Value
This should be obvious but usually isn’t. People struggle to realize that more-faster is not a software strategy. Or really a good strategy for anything with software development. More lines of code is not a good thing. More testing is not always a good thing. More stuff in the backlog actually a bad thing. And a higher Velocity does not mean your software is providing value to its customers.
We could deliver 30 things that nobody uses or hates to use. Or we could deliver 10 things that people use and like using. Or at the very least understand how to use and isn’t buggy and hated. Which would you rather have?
Closing
Teams, and mostly managements unhealthy obsession with Velocity causes a numerous amount of bad things.
- Burnout – Working nights and weekends
- Stress
- Conflicts between team members
- Gamification and lying about numbers for reports
I would rather ditch Velocity as a metric altogether and use Lean Metrics like Cycle Time, Lead Time, Throughput. And focus of forecasting using these metrics. With using these metrics, I like to then shift my energy from determining Velocity with Story Points, to improving Flow Efficiency.
And perhaps another post of Lean Metrics is coming soon…
Chris Pipito 