As most can tell by now my thoughts towards estimation in software and Story Points in particular are not very favorable. I will admit my bias and own it. But I try to keep an open mind when approaching any topic. However, when the creators of Agile and the creator of Story Points all come out against using them, I think it is time we listen.
Ron Jeffries has been quoted multiple times by many people including myself and now I will share it direct from his blog post on Story Points Revisited. https://ronjeffries.com/articles/019-01ff/story-points/Index.html
“I like to say that I may have invented story points, and if I did, I’m sorry now.“
And Martin Fowler on a blog post about the purpose of estimation https://martinfowler.com/bliki/PurposeOfEstimation.html
“In this narrative, effort put into estimates is, at best, waste – since “an estimate is a guess in a clean shirt” [2]. Usually estimates end up being actively harmful as they encourage FeatureDevotion, a nasty condition where people start valuing ticking off features more than tracking the real outcome of the project.[3]“
Even Ken Schwaber, co-creator of Scrum has intentionally left out Estimation and Story Points from the Scrum Guide and called out Velocity and Capacity worries as waste in his blog post Waste Not.
“I suspect, unless convinced otherwise, that any time we spend worrying about velocity or capacity is waste, not adding a whit of value.”
Ken’s statement is where I would like to pick up from and discuss something I am all too familiar with.
Estimates via Story Points = Time
Perhaps the most troubling, although there is quite a bit to be troubled about when it comes to software estimation and how it is misused, is the act of equating a Story Point directly to a unit of time and then using that as a means to track capacity.
This is nothing more than micro-management. And is usually accompanied by the active use of words and phrases such as; “Resources”, “Resource Allocation”, “Capacity Planning”, and “Proper Resource Utilization”. My advice to anyone who hears these words on an interview, is to run, run far away. If you inherit this culture somehow, start to have conversations around people and how much worse it is to work this way instead of in a humane way realizing that people are not “resources”, they are human beings. Bring leadership and the people together more often with Gemba walks and start to shift the culture. If leadership however is willing to refer to people as resources to their faces, then unfortunately, I don’t think much, if anything, will ever change.
Story Points equaling a standard time become painful in a multitude of ways. First, management will hold you to that time frame. And if you are late, now you have to learn to estimate better. Also having a Story Point equaling a standard time is another example of management dictating to teams what they will do to estimate and of what scale. Again, not a very pleasant way to work.
Now you might say, “fine, we will just use time.” Ok, what from the scenario I just laid out has changed exactly?
All of this is in an effort to track people and what they are doing. It has precisely nothing positive to do with the outcomes of the software being delivered. It does have some great negatives when it comes to the software being delivered.
Using Story Points to predict when something will be done is troublesome and wasteful. This is true since it is seldom accurate and puts unnecessary pressure on people to make the deadline of their estimate. What happens when that pressure starts to build towards that self-imposed deadline that management will hold you too? Well, corners are cut, quality suffers, or worse, teams start to game the estimates with a “under promise, over deliver” approach.
The tracking of the estimates over time and comparing them with what actually happened is extremely wasteful. The act of doing this only supports the “this team needs to get better at estimating” culture.
And perhaps the worst offender of the estimation world, especially with Story Points, is velocity. And velocity tracking does far more harm then good, especially when it gets outside of the team. What often happens when multiple teams are actively tracking velocity, and then those metrics are shared with management, teams are then compared on their estimations. And then teams are driven to improve or fall in line with how they are estimating.
What I am getting at is the weaponization of velocity. Velocity, in reality, is actively killing agility. Velocity shifts the focus from quality Outcomes of the software to measuring the amount of software output. Which leads back again to probably my favorite actively destructive topic of the “More Faster Culture”. I write about this often as it seems to be spread across the software industry like a cancer.
This more faster culture supported by Story Points, Estimation, and Velocity tracking also further removes the Makers from the Customers. When we focus on “getting things to done to support the estimation and velocity”, we are moving the ownership of when the software is “done” to the team instead of the customer. Remember, we build software to solve objectives, goals, and problems for our customers.
The part of all of this that really concerns me is that teams actively do this to themselves. They want to discuss why their estimates are not accurate enough. Or how to improve their estimation practices. The idea of “Planning Poker” as a means to gain shared understanding of a User Story is patently false. If you have to resort to planning poker for the team to get on the same page as to what the goal of the software they are building is, you’ve got bigger problems then even the most accurate estimation can solve.
The reality of Story Points for estimates is that even the creators of such things no longer use them or support them. In fact, if you ask them, they will tell you that they would routinely fail to meet their estimates and more over what they had initially expected to achieve in their iterations/sprints. The creation of Story Points for estimates and there usage as “velocity” was to appease management. It was known when they were created that they were complete waste in their process and held no value at all. Here comes Ron again;
“I no longer recommend velocity, which means that I also no longer recommend story estimation in points or other measures.”
“In my thinking, velocity is an obsolete topic. Out there in the world, estimates will be with us for a long time and will be misused. They were before Agile came into being, and will be for a long time to come. For my part in it, I apologize.”
Story Points and estimation are not a core part of agile software development. Yes Story Points came out of XP with Ron Jeffries, and Velocity was created to track those Story Points, but if you have read to this point, you should know how he and others felt about them then, and feel about them today. The hard truth about these things is they were created to provide something to the project management people to get them to leave the team alone so they could work. I know this is not going to win me any brownie points with most large organizations and the PMO world. But those places and organizations and I would be like oil and water anyway, so it is not my concern.
But, to echo a previous statement. If estimating with Story Points and tracking velocity is something your team or organization finds valuable and you like doing it, by all means, live and be well!
Chris Pipito 
One thought on “Killing Agility: One Estimate at a Time”