Velocity – a fallacy often blamed on Scrum

Overheard someone saying the other day – “Point based estimation is still a pointless metric and so is the velocity calculation in Scrum”. Yes I strongly disagree, not because I believe in the fallacy called velocity but because it has nothing to do with Scrum or being agile. Scrum is not a silver bullet, agree, but that comment clearly indicates a misguided anti-pattern. I am not a Scrum fanatic unless I wouldn’t create XDE, but this concerns every Agilist out there. It is about the trend of misinterpretation and the habit of many professionals to modify an immutable framework.

Scrum being a framework (not describing a method or practice) is being misinterpreted by many even after it’s 20 years of existence. While many organisations are still learning and implementing Scrum, we see more and more discussion around “Velocity” and “Point based estimation” which is not even part of Scrum in the first place (no mention in Scrum Guide).

Capacity is what we should focus on, not Velocity.

Velocity calculation is a result of the point based estimation techniques, which are also misused as a performance metric. Ask an average Scrum team how they measure team performance, the first word will be Velocity. Be it linear or relative estimation, when we use a number for anything, our beautiful minds translates it to an “absolute value” which is not negotiable. We start writing it in a card or add it on a tool to track velocity. Then we slowly & voluntarily dive into deeper political horizon of team velocity comparisons, false sense of predictability to never come back out again.

Intention of point based estimation is to break the ice.

Technical experts are usually shy, they love to just to get it done, write the code or test while listening to their favourite music. Estimation sessions gives them an opportunity to open up and be valued for their knowledge. They agree or disagree or share a fact that no one thought about before, to establish a shared understanding. Then they leave the room to start working on it but never leave the number behind. It stays in the card/tool and makes them uncomfortable when they find out a hidden issue which will screw the estimated number. This is frightening, as it becomes a matter of their honour and a measure of their knowledge, which makes them look retarded in front of their team.

“We said it’s 5 but now it seems like a 13, WTF ! If I tell the team they will think I am stupid.” – This, we can live without. This stops us from being brave and fail fast as failure is not an option. To be agile we need to embrace failure as learning opportunities. This negative Hawthorne effect goes against agility and get blamed on Scrum because of the time boxed sprints where velocity really applies.

We “estimated” the avg. velocity as 40 but it somehow becomes a “promise” to stakeholders which is not open for negotiation in many cases.

It creates an obsession among us to match the velocity every time or more to show off. Truth is, Velocity can easily be manipulated and somehow the “people” aspect get thrown out the window. Where is the trust? Where is the working software? That’s why, even though the point based estimations and velocity calculation were created to “guide” us, as human beings we cannot trust ourselves on showing our true nature – urge to control the uncontrollable. Therefore, to become agile we have to let go of this metric from Scrum, for good. We don’t want to be that person who focuses on these numbers and not outcomes.

Let’s get back to the basics of Agility

  • The fact is, we try to measure the scope in units like time, but we can’t. That doesn’t mean we have to use numbers. Be creative and find another way which doesn’t promote false sense of control over the development cycle. It’s development not manufacturing, you will fail many times before finding the right product. Scrum is for development not manufacturing.
  • RTFM – there is a reason Scrum has a guide so stop associating Velocity and Estimates as a “mandatory” Scrum metric while implementing. You are digging your own grave by doing so.
  • Stop asking Scrum Masters to report velocity as a metric. Even if they are in place, they are private to the teams, not open for all.
  • If you can’t negotiate, you are NOT agile. You might as well do Waterfall, it will give you the same results.
  • Stop making “Promises” on deadlines using velocity. If a person have never worked hands on in a code base, their knowledge about the product is at best worthless. If that person is making promises by predicting velocity, the joke is on them.

End Note

Velocity is a fallacy, whether you like it or not. Use it only if you are still winning. If you are failing then please let it go, just don’t blame it on Scrum. Scrum is much powerful without it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s