Story Points Usage by Agile Teams & Australian Camels

In Australia, there are about 1 million feral camels.  Today, they serve no purpose. In fact, they make a serious negative impact on the environment. Camel is not a native animal in Australia. So the real irony is, these feral camels in Australia is a completely man-made problem.

Anyway. This post is not about camels in Australia; this is about Story Points.

For a long time, estimation in software building was simply about “the time” it would take to do some work. Today the priests of this new religion tell us not to estimate our work in Time.
Most of the disciples of this new religion go by that. So, they prefer to use some kind of T-Shirts or cards, and a vast majority of disciples use some kind of Points for Estimation. Irrespective of what this new religion says, the business still needs an approximate time-peg for the deliveries. Business needs to know... What is your approximate time-peg to complete this piece of work?
Now it is a fair question. “A”gilists tackle this fair question by taking 1 of the 2 ways.

1: Some “A”gilists tell the business folks that “this is not the way it works in “A”gile. Work should not be estimated in time”. And this becomes the biggest reason why so many business folks think that “A”gile is just a new age fad. 

2: Other “A”gilists agree it is a fair question. So, they start a convoluted process to convert Story Points to Time. But there is no such thing like standardized Story Point. Naturally, Story Point to Time is a fertile land of confusion and never-ending debates.  All this could have been easily avoided if Estimation was NOT done in Story Points in the first place.

Actually, no framework says that it is mandatory to estimate work using Story Points. And still, most of the “A”gile practitioners, treat Story Points as if it is the soul of being agile. The fact is completely overlooked that even Ron Jeffries (the man who is considered to be the inventor of Story Points), publicly said that he feels sorry for inventing Story Points. And still, Story Points are treated by most “A”gile practitioners as if their team's ability to ship better value faster depends on using Story Points.

But the real damage is in the side effect of using Story Points. The side effect is, usage of Story Points promotes a culture where a team starts celebrating *The EFFORT*, rather than celebrating *The OUTCOMES*. And this is how the race starts to burn more & more Story Points in a Sprint. Soon enough an easy way is discovered for burning more Story Points; simply by gaming the Estimation. The ultimate manifestation of this gaming is working towards… Sprint after Sprint x% increase in Velocity.
What can be a better example of gaming the numbers?

Hmmmm, Story Points...

Just like Australian feral camels, SPs serve no purpose.

Just like Australian feral camels, SPs make a serious negative impact on the work culture.

And just like Australian feral camels, SPs is completely a man-made problem.

It will be interesting to know what Ron Jeffries said about Story Points, Velocity, etc. “Slice down thinner, you will achieve more”.

After all the real objective is achieving more.
'Estimating Accurately' was never the real objective.